Slashdot Mirror
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."
That the line count increases with each new version unless you are starting from scratch?
--
Oh Well, Bad Karma and all . . .
Beer is proof that God loves us and wants us to be happy.
And how much of this lines are for core functions (Memory Managements, Scheduler, etc) and for drivers (USB, Filesystem)
Â_Â
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.
FOX NEWS.com should be BANNED from television and internet. Have the Congress take it over and give us Truespeak.
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.
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.
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...)
I wank in the shower.
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).
Attention all planets of the Solar Federation! We have assumed control! - Neil Peart
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.
Promote true freedom - support standards and interoperability.
is the same length as this...
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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)
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.
Of Code And Men
I downloaded the latest 2.6.27.2 tarball, untarred it, removed all except the "x86" folder from under the "arch" folder and ran this in the source root:
find . -exec grep -v "^$\|^\*\|^#" {} \; | wc -l
to exclude blank lines, lines starting with "#" for comments and lines starting with "*", again for comments. I realize that this excludes the "#include" statements but there number should be negligible in the overall count.
The result is 6,022,957.
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!
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.
Irony: Agile development has too much intertia to be abandoned now.
then you might as well take the lines of assembled code as the real count.
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".
/* 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>
Help stamp out iliturcy.