Linux Kernel Surpasses 10 Million Lines of Code

javipas writes "A simple analysis of the most updated version (a Git checkout) of the Linux kernel reveals that the number of lines of all its source code surpasses 10 million, but attention: this number includes blank lines, comments, and text files. With a deeper analysis thanks to the SLOCCount tool, you can get the real number of pure code lines: 6.399.191, with 96.4% of them developed in C, and 3.3% using assembler. The number grows clearly with each new version of the kernel, that seems to be launched each 90 days approximately."

Comments

Isn't that normal?

[arizwebfoot]

That the line count increases with each new version unless you are starting from scratch?

--
Oh Well, Bad Karma and all . . .

Re:Isn't that normal?

[jd]

Yes, but it can go down with optimizations and refactoring (finding duplicated code and pushing it into a function or macro, for example) and with eliminating dead code. Ideally, code size should be asymptotic to an optimal size. As you approach the optimal size, more and more of what you need to do is already available to you. As you approach the limit, the amount of special-case logic and hardcoding approaches zero, and the amount of data-driven logic approaches 100%. Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs. Simulating a computer is always going to be slower than actually using the real computer directly. In most cases, this is considered "acceptable" because your virtual machine is simply too advanced for any physical hardware to support at this time. (There is also the consideration of code changes, but as you approach the limit, your changes will largely be to the data and not to the codebase. At the limit, you will change the codebase only when changing the hardware, so if you could hardwire the code, it would not impact maintenance at all. All the maintenance you could want to do would be at the data level, given this level of abstraction.)

Linux is clearly nowhere near the point of being that abstract, although some components are probably getting close. It would be interesting to see, even if it could only be done by simulation, what would happen if you moved Linux' VMM into an enlarged MMU, or what would happen if an intelligent hard drive supported Linux' current filesystem selection and parts of the VFS layer. Not as software running on a CPU, but as actual hard-wired logic. Software is just a simulation of wiring, so you can logically always reverse the process. Given that Linux has a decent chunk of the server market, and the server market is less concerned with cost as it is with high performance, high reliability and minimal physical space, it is possible (unlikely but possible) that there will eventually be lines of servers that use chips specially designed to accelerate Linux by this method.

Re:Isn't that normal?

[Abreu]

...still, we should think about adding Asimov's three laws before we reach such an event horizon, no?

Re:Isn't that normal?

[RAMMS EIN]

``Unfortunately, as you approach the limit, the performance must drop as you've now abstracted so far that your code becomes essentially a virtual machine on which your data runs.''

I don't see that. Not all abstraction makes things slower. In many cases, abstraction lets you write code at a higher level, while still compiling down to the code you would have written if working at a lower level.

Re:Isn't that normal?

[MadnessASAP]

Well! FOR.GIVE.ME for not having read your previous one sentence interpretaion of an article based on someones opinion of a piece of literature which was authored based on a decades old view of technology. We should all now proceed to read all of AnyoneEBs comments and be enlightened by his genius insights into our world.

Core functions vs Drivers?

[bubulubugoth]

And how much of this lines are for core functions (Memory Managements, Scheduler, etc) and for drivers (USB, Filesystem)

Meh

[alexborges]

AND???

In other news, trees tend to grow up unless they tend to grow down or sideways. Sharks tend to eat anything they can, unless they are not hungry.

Anonymous will beat me to FP for sure, unless they dont.

Re:Meh

[V!NCENT]

Yeah so!? Cars are also getting bigger and more complex over time, so Linux must be heading in the right direction!

Did I just... ? Oh sh-

Re:Meh

[DiegoBravo]

>> trees tend to grow up unless they tend to grow down or sideways.

Of course you can expect a dramatic reduction in source code size as the 2.8 finally introduces C++, the full OO paradigm, several Go4 official design patterns, and a bit of eXtreme Programming in order to recruit more young programmers.

Re:Meh

[Dutch Gun]

That reminds me of a story about my early programming attempts:

My first computer was an Apple II+, and I learned AppleBASIC from a book that appeared to be written to teach kids how to program*. I was writing a graphical maze-crawler fantasy game (a bit like Wizardry, but much more primitive, of course). I knew nothing of data-driven programming, of course. Everything was hard-coded, every room a function, etc. AppleBASIC used line numbers, of course, and in laying out the dungeon, I started incrementing rooms by 1000 to make sure I had enough space.

Sure enough, I ran into a strange issue when I tried to create a room at line number 66000. Through trial and error, I eventually determined that the maximum line number was 65535. I couldn't figure out why they would use such a crazy number as the maximum limit.

Years later, when learning about the binary nature of computers, I saw that number again, and *click*. So, I'm not sure if 640K lines are enough, but 64K lines certainly were not for me!

* If anyone remembers what the name of that book was, I'd be in your debt. I think it had a red cover, and it had great little illustrations of a robot that made it very kid-friendly. That book launched me on my current career path. I now program games for a living, and would love to find an old copy.

Stolen code

[CRCulver]

Too bad 9,999,999 lines of that code were ripped off from SCO.

Re:Stolen code

[Tubal-Cain]

And the unique line is commented out.

Re:Stolen code

[RiotingPacifist]

only in the Debian version

Re:Stolen code

[earlymon]

Take one down, pass it around, 9,999,998 lines of code from SCO

assembler?

[TheRealMindChild]

*cough*assembly*cough*

"assembler" is the tool, not the language.

Re:assembler?

[lilomar]

Sure it is, why, I was assembly some assembler code just the other day. I was using my assemble to do it.

Re:assembler?

[hondo77]

Then again, maybe not.

Re:assembler?

[Hatta]

I realize English is hard for you, but you can usually use verbs as nouns, and nouns as verbs.

It's better if you don't. Verbing weirds language.

Re:assembler?

[Abreu]

I agree. That's why I always write "anal-retentive" as a single word, with a hyphen.

What did sloccount say the kernel was worth?

[OrangeTide]

Because we'd all like to know how many man-months something a big as the linux kernel should take to implement. And laugh at the huge price tag sloccount will put on it.

Re:What did sloccount say the kernel was worth?

[bendodge]

Ohloh has a COCOMO calculator, which spits out ~$181M if you pay coders $55,000 a year.

http://www.ohloh.net/projects/linux
http://en.wikipedia.org/wiki/COCOMO

Re:Lines of Code

[theaveng]

I used to have GEOS on my Commodore 64. I have absolutely no idea how many lines of code it used, but it could squeeze itself into just 20 kilobytes of RAM, and yet had lots of functionality (as good as an 80s-era Mac). I consider "how much RAM occupied" to be a FAR more useful metric.

I would love to see someone develop an OS that followed a similar philosophy of using as little RAM as possible.

Reply from actual kernel developer please . . .

[EraserMouseMan]

I'm a developer and was wondering what kind of testing is done to verify the code. Do they use unit testing? Regression testing?

I'm just curious because keeping 6+ million lines of code almost completely bug free is pretty amazing.

Re:Reply from actual kernel developer please . . .

[Anonymous Coward]

Almost completely bug free? What are you smoking?

Re:Reply from actual kernel developer please . . .

[vally_manea]

there is at least the linux test project http://ltp.sourceforge.net/ I see a lot of unit, regression testing and stress tests.

Re:Reply from actual kernel developer please . . .

[Kjella]

From what I've gather, pretty damn near "all of the above". One of the nicer things about being a high-profile open source tool is that a lot of people are interested in researching automated code analysis on it, be it unit testing, regression testing, static analysis, dynamic analysis or whatever. And having a quality nazi on top helps. Here's what happened a few days ago on the dri-devel list from Linus:

"Grr.

This whole merge series has been full of people sending me UNTESTED CRAP.

So what's the excuse _this_ time for adding all these stupid warnings to
my build log? Did nobody test this? (...)"

In many places, you can do a pretty lousy job and still collect a paycheck. Something tells me you won't get many patches in the kernel that way.

Re:Reply from actual kernel developer please . . .

[MobileTatsu-NJG]

I'm just curious because keeping 6+ million lines of code almost completely bug free is pretty amazing.

Yes, that would be amazing.

Re:Reply from actual kernel developer please . . .

[PeterPlan]

http://www.youtube.com/watch?v=L2SED6sewRw Your question is answered in this talk. Briefly: The only way to test a kernel is to actually use it.

Re:Reply from actual kernel developer please . . .

[ZombieRoboNinja]

>>There are literally thousands of men runnning the code on even more setups regularly

Plus upwards of 7 women!

Re:Reply from actual kernel developer please . . .

[earlymon]

I'm a developer and was wondering what kind of testing is done to verify the code.

Guinea pigs. Millions of us.

Re:Um

[binarylarry]

Yeah but you can customize the Linux kernel. If you don't want features, just don't compile them in.

It's easy, there's even a gui interface.

Good luck compiling a custom NT kernel. :)

Re:Lines of Code

[megamerican]

Exactly. The better metric would be how many Libraries of Congress the kernal is.

Line Count Not Always a Good Thing?

[linuxmeepster]

It's significantly easier to hide a malicious backdoor inside a huge software project than a small one. Linux has already had a near miss back in 2003, when the CVS repository was compromised. Considering how many mission-critical applications run under Linux, there's a huge financial incentive to hide a backdoor somewhere in those 10 million lines.

Re:Line Count Not Always a Good Thing?

[Microlith]

While Linux is huge, for a backdoor to be successful it would need to hit a huge number of systems. The majority of the kernel at this point tends to be drivers, not all of which are used in a given kernel.

For it to be even remotely worthwhile, it'd have to be placed into something that was both heavily used AND given little attention. These two positions are almost mutually exclusive.

Can anyone think of a place that would fall into these two categories? Even the more seemingly obscure parts of the kernel get attention fairly often and malicious changes wouldn't go unnoticed for long.

Re:Line Count Not Always a Good Thing?

[Kadin2048]

My understanding of the Linux kernel development process is that only a relatively small number of people can make direct commits to the code repository. The vast majority of contributors have to send in patches to a maintainer, who then looks it over and gives it a thumbs-up/thumbs-down before committing it.

The kernel maintainers, by and large, are not stupid. So unless you are talking about getting one of them involved in your evil scheme, or being a sort of sleeper agent and worming your way up until you could get made a maintainer yourself (and you'd really need to be a maintainer of a central part of the code, not just of some driver piece somewhere, to be able to do much damage), you'd have to write your backdoor in a subtle enough way that it wouldn't be detected. That seems non-trivial, to say the least.

While I do suspect that the increasing size of the kernel does make the possibility of a malicious contribution larger, I'm not sure it's a very big threat even with that considered. The bigger problems seem to be ensuring continued high quality and cleaning out cruft, since while very little code will ever be malicious, all code will get old eventually.

Happy Ten Million, Linux!

[Drakkenmensch]

Now, where do we find a birthday cake with ten million candles?

Re:Happy Ten Million, Linux!

[Anonymous Coward]

Now, where do we find a birthday cake with ten million candles?

At John McCain's Birthday Party?

Re:linux kernel getting bloated

[QRDeNameland]

15. The Residents - Not Available

If Obama is missing that record, I'd be glad to lend him my copy.

What about the other .3% ?

[damn_registrars]

96,4% of them developed in C, and 3,3% using assembler

That leaves .3% that is unaccounted for. What was it written in?

Re:What about the other .3% ?

[atomic-penguin]

Visual Basic 6.

Re:What about the other .3% ?

[glavenoid]

Makefiles, build scripts, etc., perhaps?

Re:What about the other .3% ?

[mx119]

That leaves .3% that is unaccounted for. What was it written in?

Asgard?

Re:What about the other .3% ?

[macbuzz01]

It's a GUI interface in Visual Basic to see if they can track an IP address. Yes that does take approximately 3000 lines of code, granted 2982 of them are comments explaining why vb was chosen.

Re:What about the other .3% ?

[gravis777]

From Wikipedia:

Programming languages
Linux is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&T-style" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building Linux. In 2004, Intel claimed to have modified the kernel so that its C compiler also was capable of compiling it.[24]
Many other languages are used in some way, primarily in connection with the kernel build process (the methods whereby the bootable image is created from the sources). These include Perl, Python, and various shell scripting languages. Some drivers may also be written in C++, Fortran, or other languages, but this is strongly discouraged. Linux's build system only officially supports GCC as a kernel and driver compiler.

So I am assuming that the answer is Perl, Python, various scripting languages, and Fortran

Micro-kernel vs massive kernel?

[apathy maybe]

May I suggest that large parts of this shouldn't be in the kernel at all? That there should be independent sub-systems so that in the event of a crash or panic, the entire OS doesn't come tumbling down?

So that badly written drivers (especially graphic card drivers) don't affect the stability of the entire system?

May I suggest that flame-wars are good and the EMACS is also bloated?

(And lots of other folks have already talked about the bad metric that lines of code is...)

Re:Micro-kernel vs massive kernel?

[pembo13]

I think they are including modules as well. And there are a growing number of userland drivers as well. So you can't come to a conclusion without knowing the size of the parts outside the kernel.

Re:Micro-kernel vs massive kernel?

[soulsteal]

Tanenbaum, is that you? If so, give it up! It's been 16 years and you're not fooling anybody!

Not as much as you'd think

[djupedal]

Since that many lines = approx. 125,000 pages, which = approx. 0.0175 terabytes, and... a LOC is approx. 18 TB, I'd say they have a ways to go...

I Wonder?

[TheNecromancer]

I wonder what the breakdown is of the almost 4 million lines that were omitted in the count, for blank lines, comments, etc.? I've always said that commenting your code is a very good thing to do, so it would be interesting to see what the percentage of this is comments, as opposed to blank lines (which isn't a bad thing for readability).

Re:Tell us Bill

[Tubal-Cain]

Vista had 50 million lines at Beta 2

This story

[bonch]

Basically, this story is "Linux kernel surpasses 10 million lines of code! Just kidding."

Lines of code as a metric

[qoncept]

Funny that the summary calls attention to the fact that the number of lines includes comments and whitespace without any mention of how worthless lines of code is as a metric. Someone could easily go in and add or remove newlines wherever they wanted and without changed a bit of code make it 50 million or 50 thousand.

Re:Lines of Code

[stephentyrone]

I'm in a software engineering class listening to how to use metrics on code.

No, you're in a software engineering class posting on Slashdot.

Re:Um

[Yfrwlf]

And what would be better, a kernel that you could simply include or not include certain modules without the need for compilation, making the kernel truly modular, and hot-swapping them in or out based on your needs. That would make the kernel much more powerful and also useful for "normal" users/admins who might not want to mess with compiling. But, I'm sure my argument will be slapped at by some leave-things-be get-off-my-lawn fanboy who hates the idea of scary new features like true/better modularity.

Save a tree. Let the actual devs do compiling unless someone really actually wants to see the code.

Re:Tell us Bill

[mdemonic]

Ship Date Product Dev Team Size Test Team Size Lines of code (LoC)

Jul-93 NT 1.0 (released as 3.1) 200 140 4-5 million
Sep-94 NT 2.0 (released as 3.5) 300 230 7-8 million
May-95 NT 3.0 (released as 3.51) 450 325 9-10 million
Jul-96 NT 4.0 (released as 4.0) 800 700 11-12 million
Dec-99 NT 5.0 (Windows 2000) 1,400 1,700 29+ million
Oct-01 NT 5.1 (Windows XP) 1,800 2,200 40 million
Apr-03 NT 5.2 (Windows Server 2003) 2,000 2,400 50 million

Offcourse, you can't compare a whole OS to a kernel.
Data is from http://www.knowing.net/PermaLink,guid,c4bdc793-bbcf-4fff-8167-3eb1f4f4ef99.aspx

Re:Lines of Code

[hondo77]

Why? Are you still using an 80s-era Mac as your primary computer?

Re:Lines of Code

[QRDeNameland]

If 1 Line of Code = 1 Library of Congress, you should acquaint yourself with the Enter key.

Re:Lines of Code

[rumblin'rabbit]

A better metric is the number of semicolons. Thus this

for (int i = 0; i < n; i++) a[i] = b[i];

is the same length as this...

for (int i = 0;
i < n;
i++)
{
a[i] = b[i];
}

Not very informative.

[hey!]

This article summary is not very informative. The very least they could do is tell us which ten million lines of code Linux has surpassed.

A thousand Unix System 6 kernels.

[Ungrounded Lightning]

The better metric would be how many Libraries of Congress the kernal is.

Perhaps better would be number of times the size of the Unix System 6 kernel.

That's the one that the University of Waterloo printed as a textbook, half of a two book set. (The other book was the OS course text using it as the example.) They printed it at 50 lines per page column and added (lots of) whitespace and adjusted comments so routines fell on nice page boundaries. Even padded this way it came out to a total of ten thousand lines (of which I think 2 thousand were still in assembly code). Just right for one person to maintain full-time by the then-current rule-of-thumb.

So the linux kernel is a thousand times the size of that (whitespace-padded) version of the Unix kernel.

Function Point Analysis

[hierophanta]

i believe a more appropriate measure of the 'bloat' (i.e. useless functions) or the size of any software package is through function point analysis--

http://en.wikipedia.org/wiki/Function_point

http://www.softwaremetrics.com/fpafund.html

the lines of code metric has long been considered an inadequate measure of software cost, complexity, or size - here is an article on why:
http://www.creativyst.com/Doc/Articles/Mgt/LOCMonster/LOCMonster.htm

but LOC is without question one of the easiest measurement (aside from total package size in bytes, which is nearly as uninformative)

Re:Function Point Analysis

[DrVxD]

i believe a more appropriate measure of the 'bloat' (i.e. useless functions) or the size of any software package is through function point analysis

I recall many years ago, a PHB (this is long enough ago that nobody called them that yet) was talking about developer productivity metrics; he announced that the powers that be were considering either KLoC or Function Points. The guy sitting next to me said "I have no idea what function points are, but they've got to be better than KLoC". The remark made one of those wonderful whooshing sounds as it sailed straight over the PHB's head...

LOC is without question one of the easiest measurement (aside from total package size in bytes, which is nearly as uninformative)

+1 - Fundamental Law Of Physics.
LoC's only redeeming feature as a metric of anything is that it's (relatively) easy to measure. Of course, there's the debate about "do we count comments", "do we count whitespace", "how do we count curly braces" - so it turns out it's actually NOT all that easy to measure. But don't let a PHB hear you speaking such heresy...

Re:Um

[Grokmoo]

I think that what you are suggesting is already standard fare for the Linux kernel.

Typically, the kernel and all modules are precompiled. Then, modules are swapped in and out as needed.

Re:Tell us Bill

[Poltras]

Kernel only or included soft included? Because if you count included soft, it doesn't make it a fair comparison. And note that the whole graphic subsystem is included in there also, so add X11 to the lot... but whatever, comparing the number of lines of code is akin to comparing the number of bolts in a car.

it's interesting information nonetheless. Divide the number of bugs by the number of LoC and you get a better-than-industry ratio in both cases. Which says a lot.

gratutitous complexification

[cthulhuology]

This only proves that the Linux Kernel is in need of a significant refactoring effort. The capacity for any single developer to understand or even read a significant portion of this code is NIL. As a result, the opportunity to reduce duplication of effort is quickly diminishing, and the ability of new users to contribute anything other than additional bloat is similarly diminishing. And while the core of the kernel may be "small", and much of this code is dealing with special cases for specific hardware, because of the size of the code involved it is increasingly difficult to identify what is substantial and what is merely stylistic differences between two drivers. Increasing LOC counts is a sure sign of under analysis and over reliance on the availability of cheap labor. You can pick any arbitrary number of lines of code (less than say 20k) and pick that as the number of lines the kernel should occupy. As an individual line may define a new abstraction, LOC represent a potential for a geometric increase in complexity. So either these 6-10 million lines of code represent some truly staggering level of irreducible complexity (most unlikely), or are merely the result of not refactoring the code sufficiently (most likely). This really is a milestone in gratuitous complexification that should be morned, not hailed.

Re:Can this be converted into kloc ?

[DrVxD]

You could try:

              DIVIDE SLOC BY 1000 GIVING KLOC.

Kernel Modules

[mechsoph]

And what would be better, a kernel that you could simply include or not include certain modules without the need for compilation, making the kernel truly modular, and hot-swapping them in or out based on your needs.

If you're actually serious, (sarcasm is kind of hard to detect in plain text): man modprobe. Since Linux 2.0.

Re:Kernel Modules

[mechsoph]

not having to compile modules

Uh, you don't compile modules. The distribution vendor does.

actual real modularity on the binary level for true "modules"

If you want a stable kernel module ABI, that only matters for binary-only modules (which are a bad idea). See vmware for how source-distributed modules can work fairly painlessly.

meaning settings or whatnot that have to be compiled into the kernel, instead of being switches and modules that you can throw in and out of the kernel.

What are you talking about?

I don't think it's *all* modular,...as well as making it easier to swap stuff in and out.

Most vendors compile generic kernels with just about all functionality put into kernel modules. What more do you want than modprobe, rmmod? Pretty buttons?

so any increase in that helps by making the kernel easier to work on because you can have definite targets and functionality

If you want a micro-kernel, go use QNX, hack on herd, or watch as Linux slowly steps in that direction. Maybe read some of the various flame wars on the topic and consider why herd hasn't made any significant progress in 15 years.

In other words, actual driver modularity! So users can actually download and install drivers from off the intarwebz without having to compile them and Linux can actually, I dunno, be usable for 99% of users! Brilliant!

Yeah...[/sarcasm]

Re:Um

[RiotingPacifist]

In addition there is also ksplice, to swap the actual kernel too.

"Actual" code?

[TuringTest]

Comments are also code.

If you only count as code what can be feed to the machine, you should look at the size of the compiled binary. Source code is meant to be read by *humans*, so comments do count. That's why the GPL requires them to be left in the files (the "preferred form" to edit), otherwise it wouldn't be source code.

Re:"Actual" code?

[bonch]

Source code is meant to be read by a compiler. Comments are not code; they're documentation ignored by the compiler. By your standards, anything that makes source code human-readable should be counted as source code, including white space or even external documentation files!

Re:"Actual" code?

[bonch]

I don't really care much about theoretical programming paradigms. "Code" refers to the instruction statements written in a programming language for a compiler to interpret, not the comments written off to the side that the compiler ignores.

Re:"Actual" code?

[joeman3429]

then you might as well take the lines of assembled code as the real count.

Re:Lines of Code

[Randle_Revar]

>at 100 characters per line

No no, you are thinking of Java. Linux is written in C

Re:Lines of Code

[TeknoHog]

I'm in a software engineering class listening to how to use metrics on code.

No, you're in a software engineering class posting on Slashdot.

You are likely to be eaten by a GNU.

Re: so freaking what?

[Smauler]

the real number of pure code lines: 6.399.191, with 96.4% of them developed in C, and 3.3% using assembler.

Personally I thought the news was that no one knows what 0.3% of the linux kernel is written in. THAT'S news! (I'm betting it's BASIC).

Re: so freaking what?

[colmore]

It's COBOL, that crap is still just everywhere.

Re:Lines of Code

[smellotron]

Check out cyclomatic complexity. It basically measures the number of different execution paths you can go through in a given function. It's not quite what you're looking at, but it's close. It's also closely related to the nesting depth of conditionals/loops, which is a good way to eyeball conceptual "size".

Selected comments from the Windows Kernel

[symbolset]

/* 3k lines of workaround for 8 lines of code. WTF were they thinking? */

//This might work.

//Blocks undocumented interface used only by WordPerfect.

//Passes test. Ship it. I'm done. <Allchin>

Re:Lines of Code

[Just Some Guy]

No but a modern PC running windows uses 1000 times more RAM than GEOS Commodore 64, but doesn't really do anything extra. The OS needs to go on a diet.

GEOS supported thousands of printers, hundreds of hard drive adapters, hundreds of video cards, streaming network video, 3d gaming, virtual memory, several CPU vendors, hundreds of mice, and all that in 20KB of memory? Impressive!

Less sarcastic answer: modern computers do a whole awful lot more than GEOS did.