Slashdot Log In
Linux Kernel Surpasses 10 Million Lines of Code
Posted by
timothy
on Wed Oct 22, 2008 01:32 PM
from the nice-round-figures dept.
from the nice-round-figures dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Stolen code (Score:5, Funny)
Re:Stolen code (Score:5, Funny)
Parent
Re:Stolen code (Score:5, Funny)
only in the Debian version
Parent
assembler? (Score:5, Informative)
"assembler" is the tool, not the language.
Re:assembler? (Score:5, Funny)
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.
Parent
Re:assembler? (Score:5, Funny)
Sure it is, why, I was assembly some assembler code just the other day. I was using my assemble to do it.
Parent
Re:assembler? (Score:5, Informative)
Parent
Reply from actual kernel developer please . . . (Score:5, Interesting)
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 . . . (Score:5, Funny)
Almost completely bug free? What are you smoking?
Parent
Line Count Not Always a Good Thing? (Score:5, Interesting)
Happy Ten Million, Linux! (Score:5, Funny)
What about the other .3% ? (Score:5, Funny)
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% ? (Score:5, Funny)
Visual Basic 6.
Parent
Lines of code as a metric (Score:5, Insightful)
Not very informative. (Score:5, Funny)
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.
Re:Lines of Code (Score:5, Interesting)
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.
Parent
Re:Lines of Code (Score:5, Insightful)
Parent
Re:Lines of Code (Score:5, Funny)
Exactly. The better metric would be how many Libraries of Congress the kernal is.
Parent
Re:Lines of Code (Score:5, Insightful)
Parent
Re:Lines of Code (Score:5, Funny)
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.
Parent
Re:Lines of Code (Score:5, Interesting)
is the same length as this...
Parent
Re:Um (Score:5, Informative)
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. :)
Parent
Re:Micro-kernel vs massive kernel? (Score:5, Funny)
Tanenbaum, is that you? If so, give it up! It's been 16 years and you're not fooling anybody!
Parent
Re:Meh (Score:5, Funny)
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-
Parent
Re:Isn't that normal? (Score:5, Interesting)
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.
Parent