https://www.phoronix.com/news/Linux-Kernel-Nearly-40M
Ahead of the Linux 7.1-rc1 kernel release due out later today for closing the Linux 7.1 merge window, I was curious if all the code removals would lead to a negative change in line count over Linux 7.0. The removals were not enough and Linux 7.1 Git is fast approaching 40 million lines.
With Linux 7.1 removing ISDN, ham radio, and other old network driver code that yielded a 138k lines of code reduction, I was curious how that would impact the line count for Linux Git. Plus removing some obsolete PCMCIA drivers also happened for Linux 7.1 as did removing some PCI drivers and beginning to remove support for Russia's Baikal CPUs. Linux 7.1 also began decommissioning of the Intel 486 CPU support but that doesn't have much impact on the line count yet, more removals around now useless i486 bits will come in future kernel cycles.
The Git repository for Linux v7.0 came in at 39,621,378 lines between 4,991,874 blank lines, 4,737,829 lines of code comments, and then 29,891,675 lines of detected code as measured by the cloc program.
Even with the removals, Linux 7.1 is still growing larger. Linux Git as of this morning measured by cloc came in at 39,880,636 lines -- or roughly 259k lines of code added this merge window even with all the removals that took place. That 39.8M lines is between 5,015,790 blank lines, 4,775,889 code comments, and 30,088,957 lines as measured by cloc. So Linux 7.1 crossed the threshold of 30 million lines of detected code while with the blank lines and code comments is fast approaching 40 million lines. For the Linux 7.2 cycle is presumably when it will breach 40 million lines in total.
While at it, I also took a read of the current size of the drivers/gpu/drm/amd area with AMDGPU and AMDKFD along with associated code like the display core (DC) and all the auto-generated header files for each GPU. In Linux 7.0 the modern AMD kernel graphics driver stack was at 6,049,235 lines and now rose to 6,162,946 in the current Linux 7.1 Git state.
(Score: 5, Funny) by turgid on Sunday May 03, @08:06PM (1 child)
Vibe code it. In Rust.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Thursday May 07, @01:37AM
(Score: 4, Funny) by turgid on Sunday May 03, @09:33PM (15 children)
Gemini, please rewrite the Linux 7.0.0 kernel source archive in Rust.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Funny) by turgid on Sunday May 03, @09:43PM (7 children)
Here goes:
rewrite linux 7.0.0 in Rust
Followed by a bunch of bullet points.
Please rewrite Linux 7.0.0 in Rust.
Other waffle follows.
If you start rewriting it now, then by they time they've built all the new AI data centres, you should be able to do it soon. The greatest journey starts with a single step.
Then a load more bullet points and waffle.
Why are they using Rust and not Ada? Ada is better than Rust.
And some bullet point waffle.
We're on the B Ark, aren't we?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Touché) by Anonymous Coward on Sunday May 03, @09:53PM (5 children)
Rewrite yourself so that you can rewrite the Linux kernel 7.0.0 in 1/10th the number of lines of code. In Rust.
(Score: 4, Interesting) by Bentonite on Monday May 04, @05:33AM (4 children)
What is Linux, if not a kernel?
Last time I checked, to replicate what you can do in GNU C, it requires 2-10x the amount of lines in Rust.
(Score: 3, Informative) by canopic jug on Monday May 04, @08:46AM
Last time I checked, to replicate what you can do in GNU C, it requires 2-10x the amount of lines in Rust.
Increased code base size is a liability. For optimal maintenance and security, the base should be as small and as clearly written as possible [medium.com], no smaller. It's a sad fact that every line of code is a potential bug [medium.com], more than one bug when said lines interact adversely as the often do. So, when conversion to Rust results in a 2x to 10x increase in SLOC [dwheeler.com], the problems with the code will grow at least linearly if not arithmetically. Bugginess should not be dismissed off hand. It is often the case that the difference between a garden variety bug and a security exploit is the cleverness of the attacker. Bugs don't stand on their own in isolation. They can often be chained together in very creative ways to achieve elevated privileges.
Then there is the political turnmoil caused by M$ control over the Rust project and the accompanying Code-of-Censorship payload it carries. At best, that turns into a denial of service attack on key developers and project leaders. More usually, CoCs end up destroying projects and gutting teams. But that is no surprise as that is not a side effect.
Money is not free speech. Elections should not be auctions.
(Score: 2) by turgid on Monday May 04, @06:48PM (2 children)
Last time I checked, to replicate what you can do in GNU C, it requires 2-10x the amount of lines in Rust.
Intriguing. Can you tell us more? Got any links?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by Bentonite on Tuesday May 05, @06:34AM (1 child)
It came to me in a dream and as expected, the dream was correct.
Inspecting librsvg-2.40.21-r1, which is C;
Runnning `cloc .` in the base directory, there are 15,534 lines of C and 1331 lines of C header, which is about 16,865 lines of C.
Inspecting librsvg-2.60.0, which is Rust;
Runnning `cloc .` in the base directory, there are 40,166 lines of Rust and 1895 lines of C and 309 lines of C header, which is about 42,370 lines.
But wait, there's more - that does not include the rust crates - it uses ~300 rust crates - running `cloc .` in the rust crates directory, there are 2,715,781 lines of Rust - so in total it took around 2,731,315 lines of Rust to render SVG's the same than in C, or approximately 160x the number of lines!
The C version also has several libraries as dependencies, but the rust version uses the same dependencies, so those were not counted.
It wouldn't be surprising if librsvg has 160x the logic errors of the original C implementation - but the whole idea of rust is to make things so complicated that there are no obvious deficiencies and therefore the backdoor isn't obvious - until you think about the selected name and realize the name itself brazenly gloats that the whole idea is to rust your big iron out (which was selected with the knowledge that almost everyone will fail to realize something so obvious).
The only way you are going to get a program that is guaranteed to be correct is via a mathematical proof on every line - as you can see, rust can make doing so 160x harder, as you have 160x the lines to prove.
I also checked GNU coreutils 9.9-r12 and that's 201,048 lines of GNU C and 69,790 lines of C header, so around 270,838 lines (it is very light on dependencies - most the dependencies are for optional features, it seems only perl and xz-utils are hard deps).
uutils-coreutils-0.5.0 is not even equivalent to GNU coreutils - it does far less than GNU coreutils (you cannot use it successfully run many existing bash scripts that use coreutils programs and/or with good performance), but that has 166,090 lines of Rust and it needs ~380 Rust crates to do everything, which is 3,223,605 lines.
uutils-coreutils also has a hard dep on the oniguruma C regex library, which is 87,361 lines of C and 2622 lines of C header.
So ~3,389,695 lines, or approximately 12x the lines to do less (I suspect much more rust will be needed to implement the missing functionality).
(Score: 2) by turgid on Tuesday May 05, @08:20PM
I really need to learn a bit of Rust to understand this more. What did they get so wrong?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Insightful) by Unixnut on Monday May 04, @08:48AM
Perhaps easier to ask the LLM to write you a C to Rust translator, then just run that against the kernel to convert it all to Rust. Or just get the LLM to re-write the kernel single source file by source file.
I mean, Linux is just getting worse with every iteration now, we might as well accelerate the process and have some fun in the meantime.
(Score: 3, Insightful) by JoeMerchant on Sunday May 03, @11:55PM (6 children)
Slightly more serious:
Can we modularize and rewrite the kernel to remove all un-necessary cruft for _our_ particular defined applications?
🌻🌻🌻🌻 [google.com]
(Score: 1, Insightful) by Anonymous Coward on Monday May 04, @12:13AM (5 children)
A bit confused, AFAIK Linux kernel _is_ modular, no? Ever try "make menuconfig" (or make xconfig or similar)?
(Score: 2) by JoeMerchant on Monday May 04, @03:29AM (4 children)
The linux kernel has modules, but is this 40 million LOC count inclusive of the modules, or is it the core?
If it's inclusive, there's yet hope.
I have a feeling this 40M doesn't include the modules - and as such, I would very much like to be able to run my system kernel without 80486 support - yes, yes, that's coming, but there must be thousands of similar examples of things we don't need that are in there anyway...
🌻🌻🌻🌻 [google.com]
(Score: 5, Informative) by ls671 on Monday May 04, @05:41AM
Apart from not inserting various modules in your kernel. You can also choose to *not* include some of the "core" functionality when you build a kernel thus ending up with an even smaller "core".
Everything I write is lies, including this sentence.
(Score: 5, Informative) by Bentonite on Monday May 04, @06:33AM (2 children)
I would suggest using your brain to think, but it seems you've rotted that with LLM use.
40 million lines includes all code in Linux - after all, it doesn't take 40 million LoC to schedule processes and provide a SYSCALL interface.
There is no separation between "core" or "modules" - prior to compiling, you configure your .config with `make menuconfig` and choose what components you want enabled - but while under "Processor type and features", you can enable or disable "AMD MCE features" and "Old AMD GART IOMMU support" for example, there is no option to disable 80486 support.
When it comes to the deemed potentially optional parts of Linux (after all, you don't have a use for AMD MCE features with an Intel CPU, or IOMMU for a CPU without IOMMU, or the i915 driver without Intel integrated graphics), you can configure to exclude them, or compile them directly into the bzImage (increases the vmlinux size, which is a problem if the /boot partition is only 128MiB or 256MiB etc), or compile them into .ko files to become externally stored modules under /lib/modules/ that can be loaded and unloaded at runtime (allows producing generic Linux images that work as a kernel across computers, with only the modules that are used loaded into RAM - although there is a problem if modules are automatically loaded on behalf of any program, as then an exploit program can load an (unused for that computer) module with a vulnerability and exploit that).
I ran cloc on `certs/ include/ block/ security/ lib/ crypto/ samples/ ipc/ tools/ net/ mm/ scripts/ io_uring/ fs/ kernel/ usr/ virt/ init/ arch/` folders of GNU Linux-libre 6.19 (it doesn't include the latest bloat, but whatever) and well (trimmed as I'm not allowed to post the whole lot by the filter);
----------------------
Language code
--------------------
C 4,794,208
C Header 1,657,282
...
Assembly 231,090
Bourne Shell 146,572
Python 71,621
Perl 30,694
make 30,171
...
yacc3,160
Bourne Again Shell 2,444
reStructuredText 2,260
C++ 1,917
Rust 1,696
lex 1,660
awk 1,593
...
----------------------------------------------------------------------------------------
SUM: 7,549,683
----------------------------------------------------------------------------------------
Running on it `drivers/` (which is pretty much all optional components), it's clear that most of the LoC is optional drivers (trimmed as I'm not allowed to post the whole lot by the filter).
Also consider that you get half or less of the source code of many drivers - the rest of such drivers is proprietary binaries, without source code, which is clearly not included in the source line counts below .
------------------
Language code
-------------------
C 13,324,945
C Header 6,198,335
...
Rust 15,983 (not including crates, which is a lot of code to implement the loading of proprietary software and not much else?)
Assembly 4913
...
-------------------------------------------------------------------------------
SUM: 36207 3037134 2769355 19,602,664
-------------------------------------------------------------------------------
(Score: 2) by JoeMerchant on Monday May 04, @01:27PM (1 child)
> after all, it doesn't take 40 million LoC to schedule processes and provide a SYSCALL interface.
Actually, had I fired up an LLM for the question it would likely have given me something more like your analysis.
Using my brain to think, my brain has watched code that used to be one-pager routines bloat into multi-million LOC modular monstrosities over the decades, many times in many areas of endeavor.
>40 million lines includes all code in Linux
A gross misrepresentation on your part - there is no way the standard application set which ships with a base Debian or other desktop configuration is anywhere near 40 million. Firefox weighs in at 30 million, Libre Office at 7 million... If yo go for the total ecosystem of what comes in a desktop, that's "hard to count" but ranges closer to a billion lines of code.
🌻🌻🌻🌻 [google.com]
(Score: 2) by Bentonite on Tuesday May 05, @06:24AM
No matter how many people make the same intentional error of referring to GNU as "Linux", Linux is only and only ever will be a kernel, which currently at 40 million lines.
Yes, the LoC of the programs in GNU and the programs that work with the GNU OS, dwarf the LoC of Linux - but that isn't surprising, considering that such programs implement far more functionality than Linux.
Debian is a GNU distro and you have the option of using Linux or GNU Hurd as the kernel.
(Score: 3, Insightful) by turgid on Sunday May 03, @09:44PM (4 children)
Wake me up when you fix the human race. I've tried my best. Now I need a rest. Night night!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Touché) by Reziac on Monday May 04, @02:39AM (3 children)
Dear God:
I wish to file a bug report....
And there is no Alkibiades to come back and save us from ourselves.
(Score: 3, Funny) by JoeMerchant on Monday May 04, @03:31AM
Dear denizen of God's Universe:
There are no bugs, only features.
🌻🌻🌻🌻 [google.com]
(Score: 3, Funny) by coolgopher on Monday May 04, @04:55AM
Closed as fix-not-planned.
(Score: 3, Funny) by Anonymous Coward on Monday May 04, @09:36AM
Have you tried turning it off for forty days and forty nights then turning it on again?
-God
(Score: 3, Funny) by driverless on Monday May 04, @06:37AM
They wanted to include systemd et al in the line count but hit a wraparound with 32-bit ints.
(Score: 2) by DadaDoofy on Monday May 04, @05:46PM (6 children)
Roughly as fat and bloated as Windows 7...
Windows NT 4.0 (checked in 1996) – 16 million lines of code
Windows 2000 (2000) – 29 million
Windows XP (2001) – 35 million
Windows Vista (2007) – 45 million
Windows 7 (2009) – 42 million
Windows 8 (2012) – 50 million
Windows 10 (2015) – 55 million
(Score: 2) by turgid on Monday May 04, @06:45PM (5 children)
How many hardware platforms does Windows run on? How many hardware platforms does Linux run on?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by DadaDoofy on Monday May 04, @08:12PM (3 children)
"How many hardware platforms does Linux run on?"
According to TFS, fewer than it used to.
(Score: 3, Touché) by turgid on Tuesday May 05, @09:08PM (2 children)
Thousands upon thousands of embedded SBC boards are supported by Linux. Many have ARM CPUs and even more exotic ones. Most of that support is in the Linux kernel tree. It's not really just a kernel, but board support too. Now, how does Windows compare? What are all those lines of code doing?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by DadaDoofy on Wednesday May 06, @09:27PM (1 child)
I'm not defending the indefensible Widows. My point is simply that 40 million lines is fat and bloated.
Why do I need a Linux with code to support "thousands upon thousands of embedded SBC boards" I don't have in my environment?
In this day and age, there is no reason why AI can't whittle away everything you don't specifically need from the kernel source code and build a slim, trim custom kernel implementation with only what's necessary in it.
(Score: 2) by turgid on Wednesday May 06, @09:33PM
You don't need AI to do that. The kernel comes with its own configuration tool. In fact, your distribution comes with the configuration file used to built its kernel. You can start with that, in the configuration tool, and tweak it to whatever you want. You did read the documentation, didn't you?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by DadaDoofy on Monday May 04, @08:21PM
Hold on. How is this even a legitimate question? It's 2026. All I have to do is summon up my favorite AI and ask it to write me a custom OS that supports one single platform - mine. What? A few million lines or so?
(Score: 3, Interesting) by fab23 on Tuesday May 05, @12:44PM
files: 71'678
blank: 3'266'336
comment: 4'465'754
code: 21'219'015
A whole Operating Systems, including compiler and more, in a little more then half of the number of lines of code as the Linux kernel only.
cloc is available in the FreeBSD Ports as misc/cloc, needs only perl and one perl package.