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."
*cough*assembly*cough*
"assembler" is the tool, not the language.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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. :)
Mod me down, my New Earth Global Warmingist friends!
Unit Testing.... Nope
Regression Testing... Nope
Its simple really. When code becomes mature or doesn't noticeably break after a period of time it gets accepted into the mainline kernel. As long as it plays well with others then it'll stay. If it causes havoc then the maintainer is called into action to fix it or it gets ripped out of the mainline kernel and good luck getting accepted again. If the code becomes unmaintained, as in getting stale from non-use or simply not updated to stay with current kernel changes, it is ripped out and left for dead.
So in all seriousness it is about code responsibly by the maintainers, the ones who created and submitted the code to be put into the mainline kernel. Code maintainers change, but good code lasts a really long time. :)
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...
Vista had 50 million lines at Beta 2
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
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.
If you're actually serious, (sarcasm is kind of hard to detect in plain text): man modprobe. Since Linux 2.0.
Bitkeeper, yes. Git, yes. But CVS?
In addition there is also ksplice, to swap the actual kernel too.
IranAir Flight 655 never forget!
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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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
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
The government can't save you.
C comments begin with /*, not #.
Try again.