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."

20 of 432 comments (clear)

  1. Stolen code by CRCulver · · Score: 5, Funny

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

    1. Re:Stolen code by RiotingPacifist · · Score: 5, Funny

      only in the Debian version

      --
      IranAir Flight 655 never forget!
  2. assembler? by TheRealMindChild · · Score: 5, Informative

    *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
    1. Re:assembler? by lilomar · · 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.

      --
      The creator of this post (Jacob Smith) hereby releases it, and all of his other posts, into the public domain.
  3. Re:Um by binarylarry · · 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. :)

    --
    Mod me down, my New Earth Global Warmingist friends!
  4. Re:Lines of Code by megamerican · · Score: 5, Funny

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

    --
    If you have something that you dont want anyone to know, maybe you shouldnt be doing it in the first place -Eric Schmidt
  5. Line Count Not Always a Good Thing? by linuxmeepster · · Score: 5, Interesting

    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.

  6. Happy Ten Million, Linux! by Drakkenmensch · · Score: 5, Funny

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

    1. Re:Happy Ten Million, Linux! by Anonymous Coward · · Score: 5, Funny

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

      At John McCain's Birthday Party?

  7. What about the other .3% ? by damn_registrars · · 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?

    --
    Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
    1. Re:What about the other .3% ? by atomic-penguin · · Score: 5, Funny

      Visual Basic 6.

      --
      /^([Ss]ame [Bb]at (time, |channel.)){2}$/
  8. Re:Reply from actual kernel developer please . . . by Anonymous Coward · · Score: 5, Funny

    Almost completely bug free? What are you smoking?

  9. Re:Micro-kernel vs massive kernel? by soulsteal · · Score: 5, Funny

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

  10. Re:Meh by V!NCENT · · 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-

    --
    Here be signatures
  11. Re:Lines of Code by hondo77 · · Score: 5, Insightful

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

    --
    I live ze unknown. I love ze unknown. I am ze unknown.
  12. Re:Isn't that normal? by jd · · 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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  13. Re:Lines of Code by QRDeNameland · · Score: 5, Insightful

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

    --
    Momentarily, the need for the construction of new light will no longer exist.
  14. Re:Reply from actual kernel developer please . . . by ZombieRoboNinja · · Score: 5, Funny

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

    Plus upwards of 7 women!

  15. Re:Reply from actual kernel developer please . . . by earlymon · · Score: 5, Insightful

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

    Guinea pigs. Millions of us.

    --
    Pathological kinda promises Path + Logical - but instead, you get stuck with pathetic.
  16. Re:Lines of Code by TeknoHog · · 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.

    You are likely to be eaten by a GNU.

    --
    Escher was the first MC and Giger invented the HR department.