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?

[TinFoilMan]

Wouldn't that also be true of most programming?

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?

[Sybert42]

A few more hardwired paths would be nice, but we can't even get beyond x86, which complicates debugging at the very least!

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?

[operagost]

I'm not a real programmer, but I believe there's such as thing as an optimizing compiler that mostly offsets what you're talking about.

Re:Isn't that normal?

[God of Lemmings]

If perhaps Asimov's three laws of robotics were practical to implement in any device possessing conscious thought; recognizing and preventing infractions themselves require another device of at least equal capability, or a additional dimensions of complexity within the original device.

It is also highly unlikely that hardware-implemented and data-driven logic and alone would be significant enough to produce an emergent consciousness.

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.

Re:Isn't that normal?

[jd]

At the limit, the code is already optimized. Otherwise, you could still perform hand optimizations, producing code that is smaller and at least as functional, possibly more so. (When you abstract out a unit of code to reduce space, you add the potential to refer to that unit of code from anywhere that it is in scope of. Often this won't be useful, so the code is only smaller. It hasn't lost any functionality, though. Sometimes, however, it is handy, resulting in code that is both smaller and more functional.)

At the very limit, by definition any reduction in the code will lead to a loss of functionality, and any transformation you apply that retains or expands functionality must lead to an increase in code size. In practice, very few "real world" programs will ever reach that limit, so in any "real world" scenario an optimizing compiler will GENERALLY be able to get you closer to that limit. But there is no compiler or programmer in the world that can ever pass that limit, given the parameters that make up that limit. Compilers may be smarter than humans in some regards about how to get closer to that lower bound, and humans may be smarter than compilers in other regards, but there will always be a totally reduced form of a given program on a given architecture. There may be more than one, but they will be identical in size, since that's how the problem is defined.

Re:Isn't that normal?

[master5o1]

Wouldn't that be true of most editing and/or continuation of a written item?

Re:Isn't that normal?

[jd]

If you've hand-turned the code into its most reduced state, such that not so much as a single opcode can be taken out without reducing the problem-space the program can handle, you by definition have the least number of points at which a vulnerability can occur. Since all further logic is data-based, not code-based, you can stop there as you can debug the code via data. This could be done the same way Intel used downloadable microcode, or it could be done by compensating for the flaw at the data level. Alternatively, if you define security as part of the problem-space, then all code which has the potential of offering a vulnerability is placed in what is known as a "security kernel". This is usually simple enough that you can actually prove it correct, at which point it is irrelevant as to whether there are any bugs elsewhere, they can't lead to security holes. This is how B3 and A1 general-purpose operating systems are written. They don't need to prove the correctness of any part outside of that self-contained unit. At this point, there are no vulnerabilities to worry about. Possibly bugs, but again you can work around those, so long as there's nothing major out there. A hard drive is only under warranty for 5 years, so you only have to be at the point where you've a low probability of needing to do a bugfix release that can't be entirely in data within that timeframe. (If it can be done in data, it's a firmware update or a microcode update and you don't give a damn.)

Re:Isn't that normal?

[Baldrson]

I agree which is part of my advice to Microsoft:

Such an engine would, of course, have some features that dynamically encached expansions (and/or "memoizations") similar to the Hotspot optimization technology that originated with the Self programming language (and was later adopted by Sun's Java Virtual Machine). Hence it would make sense to have the OS CD contain a partially pre-expanded/optimized code base.

In other words, one might, by going to a smaller but higher level of description, end up with an even larger binary image.

But there is something more important at stake in compiling from the highest level of description here:

Clarity.

Re:Isn't that normal?

[lgw]

When optimizing, speed of execution and size of the code are competing goals. The fastest code is rarely the smallest image.

When a program becomes sufficiently "data-based" that data becomes indistinguishable from code. At the end of the day, everything's a state machine.

"Proving code correct" is, of course, a myth. A "proof" that a piece of code is correct is merely a tranferrence of the need for proof from one place to another.

Re:Isn't that normal?

[jonaskoelker]

Ideally, code size should be asymptotic to an optimal size.

For Linux, that's O(n) thanks to device drivers. That is, until we make the vendors supply them.

As you approach the limit, the amount of special-case logic and hardcoding approaches zero, and the amount of data-driven logic approaches 100%

Code is data. Look into lisp some day :)

Re:Isn't that normal?

[jd]

You are correct that speed and size age generally incompatible. There are two possible alternatives to solve this. The first, which I suggested here, is to optimize for size and then place at a lower level in the system (software migrates to hardware, data migrates to software). This gives you a system that is fast because it is compact enough TO place in hardware. The second option is to optimize for speed, rather than size. Because everything is as close to linear as possible, it would be impractical to place in hardware, but you don't need to because it's already fast. Because macros don't impinge on speed (when you compile you get the same near-linear code), you can then run a source optimizer over the code. Because it is totally broken down into a very very large number of the simplest possible steps, it is possible for even a fairly naive optimizer to macro-ize the code into something extremely compact, as you know EXACTLY where each and every re-use of code takes place. It's not hidden by differently phrasing the same logic.

My use of "space per unit of functionality" could equally well be written as "speed per unit of functionality" - for a given architecture and language, a given set of capabilities can be expressed in many ways, some more optimal than others. As you add functionality, the probability of reusing code you already have increases. If you then go through a round of refactoring, you can increase that probability further. Then, if you optimize for space, you add arcs (at negligible cost in space) and add data (to drive the code through the correct arcs). At the limit, you have an engine that performs the core operations and everything else is done by emulating the more complex stuff via data, the same way you can do CISC-like work on RISC architectures through software emulating the instructions you need.

Now, what happens when you want to optimize for speed, rather than space? CISC is slower than RISC, even though everything is spelled out in full, because determining what it is you are trying to do becomes more expensive than whatever it is you're doing. To solve this, CISC chip makers went to a hybrid architecture, where you've a RISC base and a CISC layer for anything that would be too slow in pure software. In software, a completely flat program will also not be able to make good use of the L1 and L2 caches. Thus, to finish the optimization on speed, you will also end up with a hybrid system - one that uses just enough structure to efficiently use the caches but not so much that it becomes too slow. However, the source only sees this to the extent that you denote what stays folded in the binary and what is fully inlined.

Re:Isn't that normal?

[dmbasso]

If perhaps Asimov's three laws of robotics were practical to implement in any device possessing conscious thought; recognizing and preventing infractions themselves require another device of at least equal capability, or a additional dimensions of complexity within the original device.

A hail to Kurt Godel! :)

[/., please accept utf-8... GÃdel]

Re:Isn't that normal?

[dmbasso]

I know you were being sarcastic, even though there is something to be said about:

[...] of a piece of literature which was authored based on a decades old view of technology.

The thing is: a lot of people consider those laws as something practical, and that should be really implemented. What Asimov truly wanted to show (in my interpretation) is that any law could be bent by its subjective interpretations.

So I agree with AnyoneEB, an I think you should (as it seems you haven't yet) read the entire Foundation series... awesome read.

Re:Isn't that normal?

[lgw]

There's very little point in seeking faster execution once code and data are in memory these days (beyond algorithmic improvement) - only in a few special-purpose application does *anything* that happens in memory affect observed performance. But if you do need to optimize that constant multiplier, all that really matters is locality of reference.

More generally, as long as you have an algorithm no worse than O(n*lg(n)) to work with, locality of reference is *the* factor that matters. Do what you can to avoid data needed to travel over the network, then minimize local disk access, then memorize cache misses at each successive layer. Large lookup tables, once a great optimization tactic, are a bad idea today because they cache poorly. An O(n*lg(n)) algorithm that accesses data sequentially may be faster than an O(n) algorithm that accesses data randomly.

For that matter, if a progam completes quickly and only runs once, optimizing for size may actually be faster than optimizing for space, as the time it takes to read the executable from disk may dominate. It's a different world than it was last century.

Re:Isn't that normal?

[lgw]

Errr, *minimize* cache misses. Odd typo.

Re:Isn't that normal?

[DarkAvZ]

CISC is slower than RISC, even though everything is spelled out in full, because determining what it is you are trying to do becomes more expensive than whatever it is you're doing. To solve this, CISC chip makers went to a hybrid architecture, where you've a RISC base and a CISC layer for anything that would be too slow in pure hardware.

Not every CISC have a RISC base underneath. Don't assume that what intel does is the norm... in fact, intel has done that because its particular need of maintaining backward compatibility with the huge installed base of X86 software.

Re:Isn't that normal?

[God of Lemmings]

I had no idea anyone else had the same ideas themselves, but duplication of concept is inevitable. On the good side, I now have another author to read.

Core functions vs Drivers?

[bubulubugoth]

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

Re:Core functions vs Drivers?

[hackstraw]

What about the different code bases for each architecture that are only used on that architecture?

Linux runs on LOTS of architectures, and variants of architectures, and each one of those takes code to make it run, but not all of it is compiled into the target architecture. Here's an incomplete list: http://home.hccnet.nl/p.van.deurzen/linuxweb/docs/architectures.htm

Maybe its complete, but it doesn't include things like the (maybe now defunct) 16bit port that existed a few years ago, and I didn't see the coreboot Linux smashed into a bios chip.

Linus' masters thesis was titled "Linux, a portable Operating System". If he didn't then, I surely would give him an A today.

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

[bonch]

What happened is some bored tech author didn't have anything to write about, so they decided to do a Git checkout and count the lines of the Linux kernel, which would likely be over 10 million lines at this point if you include blank lines, comments, and text files. It's a completely meaningless story, especially because of the fact that actual code is almost 6.5 million lines, but it got them a Slashdot post and some ad views on their site.

Re:Meh

[T'hain Esh Kelch]

In other news, in a turn of events, Bill Gates states that 640k lines should be enough for everyone, and that Linux is obviously bloated.

Re:Meh

[Ortega-Starfire]

This is why you hire more than one person to go over the code. Or you create a small organization to review the code. Or you let the nerds of the world review the code. Or any other random solution that tickles your fancy.

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

[alexborges]

Infidel!

geek1: 2.8 shall be made on Ruby On Rails!

geek2: waz? Django is the way to go!

geek3: 2.8 is clearly a perfect use case for UML and java

geekN: $i=0; 2.8 should be made in $platform[$N] cause $buzwwerd[$i++] $buzwerd[$i++] $buzwerd[$i++] and also, thats what they teach at school nowadays.

Re:Meh

[Svippy]

geekN: $i=0; 2.8 should be made in $platform[$N] cause $buzwwerd[$i++] $buzwerd[$i++] $buzwerd[$i++] and also, thats what they teach at school nowadays.

Your code seems to be implying you want it written in PHP. Or you think that PHP is pseudo code, which we all know is Python.

Re:Meh

[alexborges]

2.8 in PHP...

Now there is an idea.

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.

Re:Meh

[eosp]

Or do it commit-by-commit. Obviously Torvalds has seen everything that he has written, and either he or his trusted cronies (Alan Cox and friends) has seen every commit since then.

Re:Meh

[Whiteox]

Usborne's Programming in BASIC had a little robot on it - but that came later than Apple II+ - A kind of a kids book, hard cover.
I think it had C64, Apple and Atari code as well for each example.

Re:Meh

[Wacky_Baccy]

It seems not to be specifically for AppleBASIC, but is this possibly the one?

This part sounds promising:

Pages and pages of program listings in tiny, all-caps, dot matrix type, with brief introductory paragraphs. Plus, funny illustrations of strangely plausible robots. Don't underestimate the appeal of the robots.

A commenter on that entry also says this, lending plausibility:

I remember checking out of copy of that book from the libray and typing games into an Apple II, making minor adjustments so Applebasic would be happy.

Amazon.com has some used ones listed -- even a couple listed as "new", with a price-tag to match! ;)

If it's not this one, then I hope you find it eventually. I've had similar somewhat frustrating experiences trying to remember kids' TV shows and various books I read as a child, and it's always pleasantly nostalgic to finally pin something down.

Re:Meh

[Dutch Gun]

It seems not to be specifically for AppleBASIC, but is this possibly the one [e-scribe.com]?

No, but thank you. The book I recall was very specifically written for the Apple II. The robot I mentioned was a bit of a mascot, very cartoon-like.

I was actually pretty lucky. I had two excellent experiences in learning to program from books. One was the AppleBASIC tutorial, and the other was a C++ book for use with Turbo C++ (actually learned C++ before C). It's funny, I recall a very technical Apple BASIC book (I think it was the official reference manual) alongside the friendly one, and a co-worker grimaced as he mentioned "Yeah, that's the one *I* learned from." As it turns out, he also learned how to program C from the K&R book - which also wasn't the easiest way to learn.

Re:Meh

[jeremyp]

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.

Why? So you can find out who the author is and go and burn his house down because he forgot to put any mention in his so called programming book about the way numerical data is stored in computers? That was rather an important section to miss out, don't you think?

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

Re:Stolen code

[eh2o]

#include "errno.h"

Re:Stolen code

[tyrione]

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

What was strange was all the duplicate Planet of the Apes references citing Heston's character damning you all to hell.

Re:Stolen code

[Palshife]

Your song is faster as a for loop.

Lines of Code

[Flyin Fungi]

Lines of code is not a good metric for performance. I'm in a software engineering class listening to how to use metrics on code.

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.

Re:Lines of Code

[megamerican]

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

Re:Lines of Code

[mcgrew]

Lines of code is not a good metric for performance.

True, but it is a good indication of bloat. Ten million lines of code at 100 characters per line is a gig (unless I got decimal places wrong); that's a lot of source. maybe somebody should be working to pare it down some?

Re:Lines of Code

[Anonymous Coward]

The amount of code doesn't always correlate to the size of the final binary. You have to consider a slew of things when considering the Linux Kernel. First of all there is a lot of architecture specific code in there since Linux can run on everything from ARM chips to Sparc machines. Also you have to consider the built in drivers that are included in the source but aren't usually compiled with the kernel binary unless you're running an embedded or specialized system. If you have ever set up building the Linux kernel anyone would see there are a giant combination of things that a person could add and remove. The Kernel size getting larger just reflects more improvements and support for a wide range of machines. The final binary of a typical kernel has grown in size over the years but not at the rate of the lines of code so I wouldn't call Linux bloated because of the shear size of the code base.

Re:Lines of Code

[entgod]

True, lines of code is not a metric for performance. What lines of code is is a pretty good metric for the size of a project.

Re:Lines of Code

[i23098]

True, but it is a good indication of bloat.

It would be good to know how many of those lines are drivers code...

It can be bloat or not :p
With Linux you don't have cd drivers to install, all the drivers are at the kernel. Drivers are added and very rarely removed. I would not call bloat something that is required for the computer to work. Sure, it can be only the computer of the maintainer ;) :)

Re:Lines of Code

[oldhack]

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

Let's not get carried away with LoC. Bag of tortilla (BoT) is the better unit for kernel.

Re:Lines of Code

[Tubal-Cain]

Lines of Code
Libraries of Congress

What's the difference?

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:Lines of Code

[V!NCENT]

Isn't a raytracing algorythm just a few lines of code? Yet Quake3 with raytracing is heavyer than Crysis...

Re:Lines of Code

[V!NCENT]

Damn Small Linux with Fluxbox?

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];
}

Re:Lines of Code

[amn108]

Who said it is?

Re:Lines of Code

[Anonymous Coward]

If you were a kernel developer, you'd know that yes, people are consolidating code all the time, to reduce LoC.

Dropping old drivers happens, too, but at a much more sedate pace, since unlike Winblows, Linux still supports 20-year-old devices.

But the thing is modular, so chances are you are never compiling more than half those LoCs, and usually a lot less than that...

Re:Lines of Code

[DerWulf]

Lines of code is not a metric of perfomance at all. It IS a (the) metric of project size and can also give you estimates on the number of bugs in the code. Maybe you should finish your classes before talking about them?

Re:Lines of Code

[jgrahn]

Ten million lines of code at 100 characters per line is a gig (unless I got decimal places wrong); that's a lot of source.

Sure, but you'll find very few 100-character lines in Linux. The average line is maybe ten or fifteen characters.

Re:Lines of Code

[Kvasio]

well, but some say that it is not the size that matters, but how do you use it.

Re:Lines of Code

[clodney]

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

Whatever for? MS-DOS or CP/M were both developed with a goal of using very little RAM. Likewise VMS and O/S 360. Are any of those the model you aspire to?

I can buy RAM for something like $20/GB, and hard disk storage for $0.15/GB. At that kind of cost, why do I care about RAM and hard disk efficiency.

Rather than effort going to a smaller RAM footprint, how about improving:

- performance per watt
- robustness
- security
- ease of use

Re:Lines of Code

[Randle_Revar]

MenuetOS is a current OS that is written entirely in assembly (x86). I seem to remember hearing that large parts of GEOS (PC-GEOS, even) where in assembly.

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

[hierophanta]

It IS a (the) metric of project size and can also give you estimates on the number of bugs in the code. Maybe you should finish your classes before talking about them?

if that is the case - how do you account for complex code? i mean you said 'project size' so i would equate that to man hours, which is surely a function of code complexity. see my post below, regarding what i think is an appropriate measure of the items you mention - project size & bug estimation.

why the attack on character at the end of your post? seems quite unnecessary

Re:Lines of Code

[gravis777]

Well, as you can fit linux on a floppy...

Re:Lines of Code

[skeeto]

Conceptually, the size of the code is how many different things -- variables, blocks of code -- a developer has to think about and keep track of in his head. For a metric, I would parse the code, then count how many nodes there are in the parse tree, or look at the depth or width of the parse tree. This gets around all of the actual formatting of the code and ignores comments.

It still wouldn't be very strong. If someone wanted to artificially inflate code, they could easily refactor in a bunch of new variables, which wouldn't do anything but add conceptual load to do code, making it worse. This operation is a feature in most IDEs.

Re:Lines of Code

[LWATCDR]

I understand your desire and there are OSs like that out there but like everything else in life software development is full of trade offs.
You have x amount of developer time and you must divide it between features, fixing bugs, and writing tight code.
Contiki is an example of favoring small code.

Re:Lines of Code

[DerWulf]

I don't need to account for complex code. Complexity is itself a metric and has no obvious relationship to lines of code. In fact, many software techniques aim specifically at reducing complexity such as encapsulation, design by contract, inheritance and the patterns pattern. Metrics are garbage if you try to interpret or derive to much from them because they suffer from that which all reporting suffers from: you get what you meassure. However, if you want to know the relative size of the codebase of two operating systems it's valid to count the lines of code. Lines of codes equals project size is almost a tautology just as number of centimeters from the ground equals height is...

I'm not attacking the OPs character either, instead I'm mocking that he tried to back up a blatantly wrong statement with an appeal to authority.

Re:Lines of Code

[Tetsujin]

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

PalmOS is the best contemporary example I can think of. When it was initially developed (between 1996-2000) hardware limitations meant that it was difficult to make a significantly more powerful hardware device with the same form factor as the Palm Pilot. (Windows CE devices were significantly more powerful - but also quite a bit bigger and generally with shorter practical battery life in those days) - hence, a whole OS built around running on 16MHz processors and no more than a few MB of storage (all RAM - comprising installed apps, application data, and dynamic allocations), very simple UI, etc.

Of course, in the portable arena, things have changed a lot - hardware's gotten a lot more powerful, to the point where Windows is actually better fitted to the hardware than Palm OS is. And on desktops - you have to bear in mind that when you're hosting terabytes of filesystem data and managing gigabytes of RAM, it's more useful to have the OS use more of that available storage to manage things more effectively, rather than minimize resource usage when the resources are decidedly not in short supply...

Re:Lines of Code

[Anonymous Coward]

maybe somebody should be working to pare it down some?

Personally, I'd much rather have a functional OS that, for instance, have drivers for whatever thing I connect to it.

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:Lines of Code

[DrVxD]

And you don't even have to change the lettering!

Not even if you measure it in Killer Libraries Of Congress...

Re:Lines of Code

[ianare]

I use python you insensitive clod !

Re:Lines of Code

[Anonymous Coward]

I'm probably going to be marked a troll but...

when did efficiency become outdated? Not every system is for the home PC either.

Re:Lines of Code

[JesseMcDonald]

The BZ2-compressed archive of the 2.6.27.1 kernel source is 49,181 KB. I consider that a decent measure of complexity; compression takes out much of the redundancy. Uncompressed it's about 350-400 MB, not a full GB.

Regardless, an increase in code size is not necessarily bloat, particularly when a lot of that size is from optional components. My core kernel (vmlinuz) is just 2MB, with about 30MB in modules, most of which aren't loaded. That's not a bad trade-off for an extremely broad range of hardware support, including nearly every variety of supported hotplug device (e.g. USB). My more limited kernel for the Eee PC -- still including most USB hardware support -- is just 7.5MB total (as a Debian package).

I expect that this would compare favorably with most other modern operating systems, given similar compatibility.

Re:Lines of Code

[JustOK]

But what if someone puts the source code into the Library of Congress?

Re:Lines of Code

[TeknoHog]

You are likely to be eaten by a whoosh.

Re:Lines of Code

[hackstraw]

There is a thing called the space-time tradeoff.

Did your C64 have virtual memory? Could it cache your binaries and files off of your nonexistant hardisk? Would you or anybody besides a tinkerer use it today for anything besides tinkering?

There's Damn Small Linux. Runs with a GUI interface w/ 16 MB of RAM, runs w/o a harddisk in 128 MB of RAM.

My laptop has 4GB of RAM, it can run Windows, Linux, and OS X at the same time. I haven't tested it, but I could run multiple versions of say Linux.

Also consider that 20k of RAM in the late 70s, early 80s, probably cost more than 1 GB of RAM today w/o any adjustment for inflation.

Linux runs on quite modest hardware requirements, but will use what is there as well. I would say outside of a dedicated realtime embedded OS, Linux is about as lean as it gets.

Re:Lines of Code

[setagllib]

You're right. In other news, fourier transform should be just as fast as random distribution.

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

Re:Lines of Code

[porl]

as an example on the other end of the spectrum, 'du -sh /lib/modules/2.6.26-rt3' gives me...

562M !!

no wonder the bloody thing took so long to compile. i'm not sure what i turned on that has made it so huge, i started from the ubuntu hardy kernel config and basically just added certain audio components to it. oh well, mine's bigger than yours :P

porl

Re:Lines of Code

[JackieBrown]

How about an OS that you can install?

I played with MenuetOS for a bit and it is impressive but not something for everyday use.

Re:Lines of Code

[DMUTPeregrine]

Or just stop using PERL.

Re:Lines of Code

[swillden]

And a full 50% longer than this:

int i=-1; while (++i < n) a[i]=b[i];

Which, in turn, is 100% longer than this:

memcpy(b, a, n*sizeof([0]));

Re:Lines of Code

[oblivionboy]

A mildly amusing snipe, until you realize that its exactly the GP's post thats causing Microsoft's troubles in the OS market place today -- and Apple's success. Vista is a bloated dead horse. And while yes, it will perform "acceptably" on current hardware (2 gigs of ram, dual core, etc), when you "downgrade" that hardware to XP, you experience for one of the first time in recent windows history, what an operating should really be like. Lite, fast and snappy. And with no real loss of functionality, which is they key point here.

On the other hand Mac OS X is already like this. In fact its last version (Tiger) works almost equally well on my orange iBook (300mhz, circa 1999) as it does on my other Intel laptop. Granted there is a speed difference, but this is mostly seen at the application level, not the OS level. Says something, huh?

And with Apple focusing almost entirely on performance optimizations for Snow Lepoard, I can't even really imagine how your comment is really relevant. The OS should be the framwork layer that programs use to hook into to do what they need. If its taking up more than 10% of any system resources in a system, something is almost definately wrong.

I'm not an Apple fanboi for what its worth. Its just insanely obvious putting the two operating systems side by side on equivialant hardware which one is faster and better, and works in a smaller memory foot print.

Re:Lines of Code

[Max Romantschuk]

I code in Python YOU INSENSITIVE CLOD!

Stupid lameness filter...

Re:Lines of Code

[Trouvist]

The same analogy about downgrading from Vista to XP holds for downgrading from XP to 2000. No loss of functionality (virtually identical kernels) and a major speed increase!

Re:Lines of Code

[master_p]

Most probably he is using Vista...

Re:Lines of Code

[isorox]

I code in Python YOU INSENSITIVE CLOD!

Stupid lameness filter...

Wow, there's a lameness filter in python? I might have to get my fellow developers to use it...

Re:Lines of Code

[electrictroy]

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

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.

Re:Lines of Code

[electrictroy]

No actually I'm using XP. Having used Vista on my brothers 1/2 gig machine, I've decided not to touch Vista. Ever. Maybe Windows 7 will operate better.

If not, I'll hang onto the XP until my PC dies and then switch to a Mac. I used Macs in college. Other than a lack of software (the "Mac version coming soon" problem), the Macintosh Quadras of the 90s were faster and cleaner than Windows 3.1 or 95. I suspect the same comparison is still true today.

Re:Lines of Code

[jeremyp]

Early versions of Unix ran on PDP-11 minicomputers. The maximum size of the virtual address space on one of those was 64Kb although you could install up to 256Kb RAM. Even in those days you got virtual memory, disk caching, UFS file system, pre-emptive multitasking, multiple users etc.

Re:Lines of Code

[enrgeeman]

that's not what she said!

Re:Lines of Code

[OrangeTide]

When I had a dot matrix I would measure code by how long I had to wait for it to print out. A 3 coffee project was pretty serious.

Re:Lines of Code

[mcgrew]

With Linux you don't have cd drivers to install, all the drivers are at the kernel. Drivers are added and very rarely removed. I would not call bloat something that is required for the computer to work

Hmm, I think I see a possibility of making my favorite OS even better.

all the drivers are at the kernel

I don't need an Nvidia driver for the computer to work if my video card is an ATI.

If there are drivers for a hundred different makes and models of viseo card, and you only have one card in the system, that seems to be a huge inneficiency, taking up disk space and possibly memory, and a possibly a hundred "if" statements to go through for the driver actually needed to initialize.

Re:Lines of Code

[mcgrew]

One three character line of code followed by 300 characters of explanation for the poor fool who comes after me who has to figure out what stupid thing I'm doing.

As I learned to code on a machine with 4k of memory and no disk (tape drive), commenting code was a hard lesson to learn. I finally learned it at the School of Hard Knocks when I had to maintain somebody else's badly written and undocumented, uncommented code.

I'm assuming with my "100 characters per line" that comments are included.

Re:Lines of Code

[mcgrew]

I originally wrote Artificial Insanity (a program that passes the Turing Test by being a stupid drunked insane smartass) in BASIC on a 16k Timex/Sinclair 1000, ported it to a TRS-80 with the same memory, then the Apple IIe, and finally translated it to dBase and compiled it with Clipper.

Clipper turned the program that would run on the Timex into a 400kb monster.

Re:Lines of Code

[i23098]

I don't need an Nvidia driver for the computer to work if my video card is an ATI.

Suppose you change video card ;)

If there are drivers for a hundred different makes and models of viseo card, and you only have one card in the system, that seems to be a huge inneficiency, taking up disk space and possibly memory, and a possibly a hundred "if" statements to go through for the driver actually needed to initialize.

That's where modules take place. Only the driver modules you require are loaded. You can even delete from your harddrive the modules you don't use. It won't take any ram space the modules you don't use.

The fact that you can make an installer that only installs on your computer the modules you require, doesn't mean that there is no source code for the modules you don't use :p

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.

Re:Lines of Code

[Yunzil]

when did efficiency become outdated?

When the cost for a programmer to make something really efficient was exceeded by the cost of just buying a faster computer.

assembler?

[TheRealMindChild]

*cough*assembly*cough*

"assembler" is the tool, not the language.

Re:assembler?

[TheRealMindChild]

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

Sure, you are right, but that has nothing to do with the softness of my toilet paper. "Assembly" is a proper noun, specifying a specific language. "Assembler" is a generic noun, indicating any number of tools that can convert "Assembly" source code into compiled machine code. Both are nouns, regardless.

Re:assembler?

[fm6]

Actually, it's the people who consider themselves English wonks that get all bent out of shape when you verb nouns and noun verbs.

Re:assembler?

[ilovepolymorphism]

Assembly is also a verb.

No, it's not.

Re:assembler?

[fm6]

As long as you're getting all usage Nazi, it's "assembly language", 'cause "assembly" is an adjective. But in informal usage, it's OK to leave off the noun and use the adjective as a noun. (I prefer to say "noun the adjective" just to piss off POS Nazis.) And as for confusing the language with the tool: WTFC? This is Slashdot, where lose lips sink looser ships!

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?

[Smelly Jeffrey]

Godwin FTW!

Re:assembler?

[OrangeTide]

Agreed. for what it's worth I meant to say Assemble. It's easy to get words switched around if they are typed nearly the same and you have been typing on form repeatedly for most of your life. C'est la vie

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?

[LordEd]

*cough* Buckleys *cough* it tastes awful but it works! *cough*

Re:assembler?

[orkybash]

Give TFA a break, it doesn't look like it was written by a native English speaker given the awkward wording of the rest of the article. It was just as likely a grammatical mistake as a technical one. Of course, that doesn't excuse lazy editors...

Re:assembler?

[Abreu]

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

Re:assembler?

[slimjim8094]

No need to be a dick. Saying you're writing in assembler (where assembler is a tool that takes operators and operands, and converts them into 0s and 1s) just sounds stupid. Plus it's wrong... like he said, assembler is a program, assembly is a language. You don't write in GCC, do you?

Re:assembler?

[DrVxD]

"Assembly" is a proper noun, specifying a specific language.

Actually, it doesn't specify "a specific language" - it refers to a class of languages.
I'm still fairly fluent in maybe half a dozen different assembly langauges, and could probably get by in another half dozen or so if I had to. (And no, I'm not counting different syntax for the same architecture, I'm actually talking about different target platforms)

Re:assembler?

[Critical Facilities]

"assembly" is an adjective

As long as we're beating a dead horse...no, "asssembly" isn't an adjective, it's a noun.

Example: This assembly is broken.

"Assembled" would be an adjective.

Example: The assembled product will resemble this picture.

Re:assembler?

[Alpha830RulZ]

Um, at various times, "Assembler" has actually been the name of the language, at least in common parlance. This was true when I last used any assembly code, back in the early 80's.

Re:assembler?

[The Iso]

"Assembled" in that context is a passive participle modifying a noun.

Tell us Bill

[b0ttle]

I wonder how many lines of code Windows has

Re:Tell us Bill

[b0ttle]

I'm not throwing punches at Microsoft, I'm just curious. Anyway, I didn't know you read Slashdot, Bill...

Re:Tell us Bill

[Tubal-Cain]

Vista had 50 million lines at Beta 2

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:Tell us Bill

[thePowerOfGrayskull]

The implied point of your original comment is that Windows is a closed-source, proprietary system. You're presumably an opponent of MS, which is perfectly fine; I totally get it. You presumably have philosophical objections to MS. Again, totally understandable. But the story is about the linux kernel, not MS. It took all of, what, 10-15 comments -- including the usual "first!" post crap -- for there to be some sort of anti-MS comment posted. If the story is about MS or something that MS somehow affects, then go ahead and rip into them. But it's a little tiring to see these MS digs in stories that, when you get right down to it, are about something else entirely.

Phew. You sure did a read a lot into one little sentence. Deep breath in... hold it... let it out. Relax. Deep breath in...

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.

Re:Tell us Bill

[b0ttle]

I didn't post an anti-MS comment. The story is about an operating system, it's natural for questions about operating systems to arise.

Re:Tell us Bill

[Fri13]

You ain't comparing Windows NT OS to Linux Kernel.

You are comparing Windows NT's Software System to Linux OS.

http://tinyurl.com/mum9x
http://tinyurl.com/3uaq48

Re:Tell us Bill

[FoxconnGuy]

"Okay, you win (vista)", says a penguin.

Re:Tell us Bill

[TimSSG]

I wonder how many //FIXME are in the windows source code~ Tim S

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?

[konohitowa]

Most SLOC tools assume that there are high level requirements documents, systems engineering documents, design documents, and fully witnessed regression tests and reports. Plus CM and QA roles performed independently. And that means those documents are updated and tests performed for every release.

2.5 hours/SLOC isn't far off of the mark in cases like that, so I'm gonna guess it was around 9300 months, which is 775 man years. So, even if we pick 1992 as the first year of Linux, that's 16 years which comes out to a staff of 48 people working full-time per year. That's not exactly a huge staff.

Obligatory "That's what she said!" added for your convenience.

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:What did sloccount say the kernel was worth?

[konohitowa]

Good Lord. I ran back through my math and found my error (fortunately, I normally use 'bc -l' and the terminal was still open). I missed a digit on the LOC. So, my numbers come up as ~94,000 months, or ~7,800 years, which would be a staffing of nearly 500 for 16 years.

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

[Anonymous Coward]

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. :)

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

[pembo13]

There are literally thousands of men runnning the code on even more setups regularly, and apparently a healthy percentage of those report any and all problems they find. And now, with the addition of kerneloops, getting problem reports is even easier.

Re:Reply from actual kernel developer please . . .

[phantomfive]

It's not bug free.

Oh, was this a troll? I'm sorry. Seriously though, I believe the strategy for testing is 'if you make a change, you are responsible for making sure it works'. Most of the code is driver code, which means it is modularized, so a change in one place won't break something in a different place. The core code is actually significantly smaller. It does run on 4MB devices, after all.

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

[Anonymous Coward]

If something has worked flawlessly for you, you might consider it to be "bug free", even if it has tons of bugs that affect plenty of other people.

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:Reply from actual kernel developer please . . .

[c0p0n]

Unix and linux dickwaving below this line:
_____

Re:Reply from actual kernel developer please . . .

[DerWulf]

haha

Re:Reply from actual kernel developer please . . .

[lordholm]

Unit testing a kernel like linux is close to impossible. I just finished the delivery of a piece of embedded software. We had requirements to test 100% of the code.

Although, this worked fine for those that wrote the application software in the system; I was working on the parts managing the network layers, and although I was able to finish testing to 100% coverage, the tests are more or less unmaintainable due to the complexity of the thing (and, not to forget that I had no access to the target hardware for doing the testing, so it was simulators and stubs for all the directly hw interacting parts).

The problem here is, that there is a level of diminishing returns on the tests: I guess that 90% of the test code was just for chasing coverage and making sure that there where stubs and virtual hardware to work with. 10% of the test code actually made sense.

In a kernel it is even more difficult. The only way to reach the same level of confidence is to make the kernel small enough to be understood by one person (i.e. a microkernel), for such a kernel you can also develop a more formal model so you can prove mathematically that the design is correct.

Re:Reply from actual kernel developer please . . .

[DerWulf]

why do you even bother? Anyone who tried out automated testing knows that there are real benefits. Of course, it's not possible to do in every situation but if you never thought to yourself "man, it sure would be nice to verify that my code still does all of what I think it should do after I completely rewrote one part" you've never written and maintained anything worthwhile.

Re:Reply from actual kernel developer please . . .

[slimjim8094]

I'd consider it WORKSFORME, because that only implies the singular person. Bug free means free of any bugs... and a bug is something that doesn't work properly. Even if you don't run that code-path, it still isn't (or wouldn't) behave properly.

Re:Reply from actual kernel developer please . . .

[ZerdZerd]

It is Linus we are talking about here. No debugging, just Linus.

Re:Reply from actual kernel developer please . . .

[ianare]

what's scary is someone modded that insightful ...

Anyway, for the record, please understand that automated testing is an integral part of any good software project.

Re:Reply from actual kernel developer please . . .

[Smenj]

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

Short answer: all kinds of testing.

• Ingo Molnar (among others) have access to huge build farms that compile- and boot-test the kernel.
• linux-next merges and builds proposed trees, and generates daily reports.
• Thousands of developers test development kernels before the stable kernel is released, each focusing on their area of interest.
• The kernel oops project tracks which kernel bugs occur most frequently.

Do they use unit testing? Regression testing?

Yes. See the Linux Test Project.

Re:Reply from actual kernel developer please . . .

[hackstraw]

"Regression testing"? What's that? If it compiles, it is good, if it boots up it is perfect.

Torvalds, Linus (1998-04-08)

Re:Reply from actual kernel developer please . . .

[konohitowa]

I tried that excuse with my DAR in an attempt to wave DO-178B compliance but it didn't work out very well for me. Fortunately, it turns out kernels can be tested.

Re:Reply from actual kernel developer please . . .

[konohitowa]

Sounds like a Level A flight critical. Yuck.

Re:Reply from actual kernel developer please . . .

[ari_j]

Linus is not a quality Nazi at all. He hasn't even once ki... Oh, wait.

Re:Reply from actual kernel developer please . . .

[ari_j]

The problem is that five of them are 95+-year-old great-grandmothers, who are not only likely to die soon and reduce that number but also really bad about submitting bug reports for things that aren't part of the kernel, such as things costing more than they used to or this newfangled toaster not working on corn chips.

And the other two don't think you counted them for some reason.

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. :)

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.

Re:Line Count Not Always a Good Thing?

[MostAwesomeDude]

One of the design goals of git was to make this impossible. All commits depend upon all previous commits, and everything is hashed and verified. Combine that with a responsible packager like Linus, and there's no real risk, since he can see *every* commit, and he would know immediately if something had changed because patches sent in would refuse to apply and tags couldn't be created or signed.

Re:Line Count Not Always a Good Thing?

[Kjella]

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?

Yes. It's called downstream and is used by pretty much everyone. All the layers of review are before it hits the main branch for release, then maintainers package them for use in distros. Upstream developers never bother with whatever the package maintainers do and anyone with a half-serious interest in any project will be asked to go to the source, the upstream source repository. If I was to identify the #1 security threat I would say a malicious or careless package manager. That's what happened in the OpenSSH security hole, which was about 11 on the goatse scale and would have made Microsoft proud - and to anyone's knowledge he wasn't even trying. Well if he had been malicious then for two years he'd pretty much have access to all Debian and Ubuntu SSH servers anywhere he could log traffic and the discovery was more or less by accident, not a security review. Now imagine a malicious maintainer that inserts a subtle vunerability like a buffer overflow that doesn't break any functionality, but that an attacker could exploit. How long would it take before that was spotted? I'm thinking years unless they're really unlucky and hit a server with an advanced intrusion detection / tripwire system.

Re:Line Count Not Always a Good Thing?

[mandelbr0t]

Can anyone think of a place that would fall into these two categories?

Things that are given little attention are those really difficult parts that tend to be done by very few people. Off the top of my head, crypto implementations are understood by few and someone who knew what they were doing could possibly hide something in there. These crypto libraries are used by the kernel in many places, so the heavy use requirement is also met. Of course, I imagine that only very trusted people are allowed to touch such code. However, I still recall this nasty Ubuntu vulnerability. I was extremely glad that my critical servers are on BSD.

Re:Line Count Not Always a Good Thing?

[fabs64]

Actually afaik no one except linus "commits" anymore. These days it's all distributed source control, so the maintainers tell linus that their feature branch is now up to scratch and linus pulls from them.

Re:Line Count Not Always a Good Thing?

[fabs64]

This is actually touted as one of the advantages of switching to git.
git tracks "content" rather than files, which it identifies using a SHA-1 hash. Meaning that if anything is changed in a repository it will be identified as a "change" as soon as someone pulls it down, and so will be vetted.

Happy Ten Million, Linux!

[Drakkenmensch]

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

Re:Happy Ten Million, Linux!

[Archangel Michael]

The cake is a LIE!

Re:Happy Ten Million, Linux!

[cryptoluddite]

More importantly, does the cake run linux. 'Cause that would be ironic...

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:Happy Ten Million, Linux!

[theantipop]

Quick, someone call John McCain and ask how they managed this for his last birthday!

Re:Happy Ten Million, Linux!

[theantipop]

Wow, owned by the wonky threshold comment hiding in D2.

Re:Happy Ten Million, Linux!

[jberryman]

Nah, McCain's birthdays started over again at zero about a decade ago.

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% ?

[jd]

0.1 was written in APL, and the remaining 0.2% was in SNOBOL.

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% ?

[RulerOf]

A relatively young language, called TIE, for "Torvalds' Insatiable Ego"

Re:What about the other .3% ?

[Drooling Iguana]

Rewrite it in Lisp, that way it'll work in emacs.

Then re-write emacs in Javascript so that it'll work as a Firefox extension.

Re:What about the other .3% ?

[jam244]

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

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

Why is this +5 funny? That's over 19,000 lines... I had the same question.

Re:What about the other .3% ?

[haploc]

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

Notepad, for the comments.

Re:What about the other .3% ?

[Amazing Quantum Man]

And then run FF on Linux.

WARNING INFINITE RECURSION DETECTED!!!

P.S. I hate the lameness filter.

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

Re:What about the other .3% ?

[hoytak]

Quiet about that one -- Microsoft doesn't want anyone to know their secret for implementing the vista kernel. It might give someone a business advantage.

Re:What about the other .3% ?

[FurtiveGlancer]

1's and 0's. This is where Linus magically hand-coded the kernel into existence. Marvel with me! Ooohhh, aaahhh.

Re:What about the other .3% ?

[ari_j]

30,000 lines of Makefiles and build scripts. All of it avoidable by using Eclipse.

Re:What about the other .3% ?

[dkf]

30,000 lines of Makefiles and build scripts. All of it avoidable by using Eclipse.

Mod parent up as Funny.

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?

[mystuff]

Mod parent up, a valid point. I mean if you compare this to the Minix kernel (on which the Linux kernel is very loosely based, or inspired if you will), it has only 4000 lines of code. 4000 vs 6.4 million!

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!

Re:Micro-kernel vs massive kernel?

[apathy maybe]

Nah, I think he's got his own account. I'm just trying to start a flame war :) (or at least get a funny mod...).

Re:Micro-kernel vs massive kernel?

[Randle_Revar]

nice

Re:Micro-kernel vs massive kernel?

[serviscope_minor]

May I suggest that large parts of this shouldn't be in the kernel at all?

No. You may not. Permission denied.

It pretty much is a microkernel in places. Look at fuse, X11, esd|jack|etc, libusb, ghostscript, and so on.

Loads of stuff is moving out/already out of the kernel: filesystems, graphics, sound, USB drivers, printer drivers and so on.

Re:Micro-kernel vs massive kernel?

[LandruBek]

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?

Yeah, so if the hard-disk driver crashes, or if the memory manager crashes, or graphics driver crashes, you can still use your computer---just without memory, hard disk, or a display. Riiiight.

(apologies to John H. Hartman)

Obvious

[eclectro]

This raises the question - will Linus run out of magic powder?

Re:Obvious

[maxume]

Only after Columbia.

Re:Obvious

[Amazing Quantum Man]

No, he uses Torgo's Executive Powder. There's a near-infinite supply of that.

Re:Obvious

[ConceptJunkie]

It also cures jock itch and makes a wonderful dessert topping.

 

Re:lameness filters

[mcgrew]

It's called a lameness filter because it's pretty lame. Try pasting the definition of a word from reference.com, or the lyrics to a longish song. Or a joke that relys on caps to be funny.

The lame mess filter won't let you.

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:I Wonder?

[Sicnarf]

A guy wrote an article just on this in the IEEE Software magazine. Looking at the graph, roughly 10% of the source code is white space and 22% are comments. See http://elis.share.googlepages.com/IEEE.Software.M.Vol.25.No.4.torrent

Re:this is news?

[SandFrog]

You cared. At least enough to add a comment...

Trust Me...

[shellster_dude]

You don't want to know.

A very fit 10 million

[renrutal]

Interestingly only a year ago the i386 and x86_64 trees merged into one, greatly reducing the SLOC count at the time.

This story

[bonch]

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

Re:This story

[not already in use]

I thought the same thing.
Headline: Linux Kernel Surpasses 10 Million Lines of Code
Summary: Actually, it's just over 6 Million

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 as a metric

[rolfwind]

Rating programmers on Lines of Code in a commercial environment seems like a way to promote bloat and slow, inefficient code.

Re:Lines of code as a metric

[barzok]

More LoC does not always mean less-efficient code. For example, in Java using Apache Commons' Logger:

log.debug();

Is slower than:

if (log.isDebugEnabled()) {
log.debug()
}

http://twit88.com/blog/2008/03/07/why-you-should-use-isdebugenabled/

Re:Lines of code as a metric

[I.M.O.G.]

Thats all well and good... But isn't it generally true that kernel devs adhere to spoken and unspoken conventions that take considerable time to familiarize oneself with?

With that said, on average lines of code are relatively uniform across and its not all that bad of a metric once you account for comments and blank lines. You don't find many lines of codes that are 10,000 characters long... They are all generally under a certain length to make them reasonably human readable. Thats the rule that makes lines of code on average fairly similar... A line could be very short, but its not going to be terribly long. So saying there are about 6 million lines of code or so means that there are 6 million lines with between 1 and 500 characters of code. Sure, sure, you could break lines wherever you want to fudge the numbers, but in practice it isn't done which takes us back to the human readable requirement.

I'm stretching, I can't say I've directly viewed the source... but my understanding of kernel development from what I've read indicates these statements should hold true.

Re:Lines of code as a metric

[supernova_hq]

without changed a bit of code make it 50 million or 50 thousand.

Anyone who can do that is a GOD considering the Linux kernel code itself is 6 Million lines of code...

Re:Lines of code as a metric

[ljw1004]

> "...its not all that bad of a metric once you
> account for comments and blank lines."

A metric for what?

And in this metric, does commented code scores higher or lower than uncommented code?

Re:Lines of code as a metric

[jc42]

without changed a bit of code make it 50 million or 50 thousand.

Anyone who can do that is a GOD considering the Linux kernel code itself is 6 Million lines of code...

I'm a bit puzzled by that. My reaction was that I could write a little perl script to do either in a few minutes, and it'd probably work correctly the first time. But I don't consider myself any sort of God. Neither would any other competent perl or python programmer. Most people who know the rudiments of either language would include the word "trivial" in their response.

It's true that the order-of-magnitude increase in lines would be easier than the decrease. This is because you'd have to do a basic lexical parse, because in C you can only introduce newlines between tokens, and that's slightly more difficult that recognizing which newlines can be removed. But recognizing a C token can be done in perl or python with a single simple pattern, so the only thing nontrivial is knowing enough about REs to write the pattern.

There's the fun extra syntactic gimmick that the rewrite rules would be slightly different for lines starting with '#' than for lines without an initial '#', but again, most perl or python programmers would just shrug, mutter "trivial", and write it.

If you don't know any language with good text-munging tools, you might find the task difficult. But since Snobol appeared back in the 1960s, we've developed a lot of languages that can handle simple text formatting trivially. And once you've written the few lines of code, running 6 million lines through it on modern machines can be done while you go out for lunch.

(Actually, I have written a few such conversion programs, usually a bit more complicated than adding or deleting newlines, and fed them millions of lines of input while I went off and did something else. In each case, it worked fine, and was as easy as I thought it would be. And I don't make any claims to godhood of any sort.)

Kernel or Kernel + Userspace?

[maz2331]

Remember, the 10M lines is just the kernel in Linux, not an entire distro (ie: kernel + GNU stuff + X + apps + all the other stuff), so a total count of Windows LOC would be comparing apples and oranges.

IE: How many LOC are in NTOSKRNL + Drivers would be a better comparison.

Re:Kernel or Kernel + Userspace?

[Fri13]

Windows NT (the OS, so called "Hybrid kernel" (what use a microkernel!)) has about 6 million LoC

Linux (The OS, a monolith kernel) has now over 6 million LoC

Windows NT5.1 software system (Windows NT5.1 = XP) is over 40 million lines of code.

Linux software system (Any distribution) can be over 40 million lines of code very easily, the KDE project is alone almost that!

Problem is that we should only count code what are in OS's (Linux vs NT) and not on whole software systems. It is easy to do count for Microsoft own code, without counting all the software what is available for Windows NT. But usually on distributions what use Linux OS, you get counted all the applications from FOSS side too, like Mozilla Firefox, Mozilla Thunderbird, KDE (alone a HUGE!), Gnome etc. All the applications what are compiled for those distributions.

The Comparison is not fair at all.

(And yes, the Monolith kernel is the OS, not just a kernel http://tinyurl.com/3uaq48 http://tinyurl.com/mum9x)

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.

the straw that breaks...

[ystar]

Sorry everyone, that was me! Silly push %ebp ... Apologies to all...

Re:Periods and Commas

[dave420]

It's quite a frequent occurrence in non-English-speaking countries. It annoys the heck out of me, and is clearly illogical, but hey - it happens.

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.

Re:Not very informative.

[registrar]

Mmmm... a pox on whoever gave the editors a thesaurus. And may he give the pox to the person who wrote the summary... the number of lines of code grows with each release?! Who would have thought...

Unfortunately none of the things they comment on---number of lines of code, release cycle---particularly reflect on the quality of the codebase or how carefully it gets reviewed. What measures that reflect the amount of time and number of edits between when a patch is proposed to when it is included? Or the fraction of files that remain unchanged?

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.

Re:A thousand Unix System 6 kernels.

[Lord Kano]

George Bush: The Republican Jimmy Carter.

I disagree. I'd say that he's the Republican Bill Clinton. No matter what shit the opposition tries to throw him in, he always seems to come out cleaner and he inspires insane hatred in the opposite party.

LK

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

kernel going bloatware

[GooglersPants]

let's see now. 10 years ago the battle cry of linux over Windows is that it's leaner. leaner being meaner and faster. now with all that unnecessary bloat code, what's linux's battle cry now?

Re:kernel going bloatware

[RAMMS EIN]

It supports more hardware?

Re:kernel going bloatware

[Dan Ost]

Drivers are unnecessary bloat? When did that happen?

Re:kernel going bloatware

[rubycodez]

there are linux distros with user apps that fit in 50mb or less that can run on 80486 with 8mb ram. All ten million lines of source don't get used for every architecture or set of devices

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 b0ttle

[b0ttle]

Ok, I'm not offended by your post.

Re:Periods and Commas

[BrentH]

Illogical? Just as arbitrary as the other way round.

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:gratutitous complexification

[unityofsaints]

This really is a milestone in gratuitous complexification that should be morned, not hailed.

Jeez aren't we lucky you at least reduced the complexity of mourned by stripping it of its 'u'? Maybe the linux kernel just needs to have all the 'u's taken out ;)

Re:gratutitous complexification

[Anonymous Coward]

This almost makes one think that you take LOC as an indicator of complexity, which is simply ridiculous. If you consider that the majority of that code tends to be in drivers and architecture code, the complexity argument goes out the window. Specific drivers and architectures are only of interest to certain people, and the vast majority of users are never going to interact with anything outside of their narrow window. While it is true that no one really understands the kernel in its entirety, it has been that way for well over a decade or so, yet things still seem to be making forward progress somehow. There is more to be said for having a strict hierarchy of subsystem maintainers and the associated trust metric for merging up, but this is the fundamental methodology that permits the system to scale so effectively.

The one thing your rant also excludes is that there is no need for someone to understand the entire system, even at the core level. The kernel is much more of a social atmosphere built around trust and interpersonal interaction. When various VM issues are encountered, all of the usual folks working in that area are CCed and left to work it out, etc, etc. It is much more an issue of knowing who to defer to in order to see results than it is someone at the top having a hand in everything. Subsystem maintainers are usually in their positions because they understand their problem space, and work in it on a daily basis. Trying to work around them or displacing that undermines the entire process.

The barrier for entry has gone up over time, but drivers now (where people usually start) are still a well documented area and one where a lot of resources and help exists to get one going. It is also arguable that writing a driver for the current kernel is orders of magnitude simpler to what it was in the pre-2.6 days prior to the introduction of the driver model, where interfacing was much more ad-hoc. While there is a lot of inherent complexity in the driver model, the vast majority of that is stuff that a driver developer simply doesn't need to care about.

Rather than whining about LOC, perhaps you can point to a few specific cases of why you believe the current system is error prone, since it seems to be working just fine for the rest of us.

Re:gratutitous complexification

[bendodge]

I'm not a Real Kernel Hackerâ (or even a Pretend Oneâ), but it sounds like refactoring it would require a very detailed Functional Mapâ of the Codeâ, since no Realâ person can go through that much. Does such a thing exist?

(I wonder how many more Trademarksâ I can fit in here...What? Stupid Slashdotâ encoding...)

Re:gratutitous complexification

[bobsledbob]

I like your comment, because I was just reading from chapter 5 of Code Complete 2nd Edition [pdf], in which Steve McConnell writes:

Dijkstra pointed out that no one's skull is really big enough to contain a modern computer program (Dijkstra 1972), which means that we as software developers shouldn't try to cram whole programs into our skulls at once; we should try to organize our programs in such a way that we can safely focus on one part of it at a time. The goal is to minimize the amount of a program you have to think about at any one time. (pg 79)

The Linux kernel is the classic example of software which no one person can, or should, have complete knowledge of every line. The kernel has long ago grown beyond even the ability for Linus himself to keep track of everything. The point is, however, that by subdividing the code, one person doesn't need to understand every line of code.

So, I think frankly you are wrong. Or at least, you are likely the wrong person to decidedly state that "the Linux Kernel is in need of a significant refactoring effort."

There are no doubt dozens of kernel hackers that have a sound understanding of all the various subsystems and how they work together. So as for judging the kernel's supposed "complexity," that's all that matters and clearly the kernel is not so complex to justify your statement.

Re:gratutitous complexification

[cthulhuology]

Quite frankly Steve McConnell and Dijkstra were both proponents of a school of programming that was just as wrong in the 1970s as they are today. The only difference is today we have had an entire generation of programmers schooled in their wrong-headedness.

If you look at the work of Alan Kay, and the people at VPRI, they are striving to produce a complete computing system in 20k lines of code. Charles Moore & friends have complete chip design CAD and simulation systems running on real world hardware written in fewer lines (and have produced actual hardware using them). Dijkstra and McConnell are apologists for a status-quo which promotes ignorance rather than valuing understanding.

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

[Yfrwlf]

I was referring to two things here, not having to compile modules, actual real modularity on the binary level for true "modules", and also anything that's not a Linux module, 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. I don't think it's *all* modular, is what I'm saying, so any increase in that helps by making the kernel easier to work on because you can have definite targets and functionality, as well as making it easier to swap stuff in and out.

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!

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:Kernel Modules

[ianare]

The Linux kernel has never been and has never claimed to be binary stable. The way I see it there is absolutely nothing wrong with having to compile modules for an open source kernel ... it's what makes the system so flexible. Given that, what you are looking for is modprobe.

And if you MUST have binary compability, look at Solaris.

Re:Kernel Modules

[Palshife]

For those curious, the references to 'herd' refer to GNU Hurd, http://www.gnu.org/software/hurd/hurd.html.

Re:Kernel Modules

[mechsoph]

Hmm, of the three vowels with the right pronunciation, I managed to pick the one that was most wrong...

What's the f* count now?

[jlindy]

10 million lines is all well and fine, but more importantly what's the fuck count up to now?... Yeah, yeah,okay I know. run --> grep -r 'fuck' /usr/src/linux* and count it up for myself... Sheesh!

Re:What's the f* count now?

[PReDiToR]

Here ya go.
http://rafb.net/p/qIBTWx15.html

I get 29 from 2.6.27.2

Huh, I didn't know the kernel was under CVS ever..

[Anonymous Coward]

Bitkeeper, yes. Git, yes. But CVS?

"Real" lines?

[TuringTest]

Comments are also code.

If you only count as code what can be feed to the machine, you should only count the compiled binary. Source code is meant to be read by *humans*, so comments do count.

Re:"Real" lines?

[2short]

Ok, now we just need a new word that means "the part of code that's not comments", because it's useful to be able to refer to that. You know, what used to be called 'code'.

Comments do not affect the function of the program, and therefore are not code. Just like whitespace (in most sane languages).

Re:"Real" lines?

[mysidia]

Although they are part of the source file, comments are not interpreted in any meaningful way, and they have no effect on the program.

Source code is not written to be read by humans, the programming language is merely a tool, and source code is written to be interpreted by computers. The only humans that generally "read" any part of the source code are people who are working on implementing the program.

Comments are merely an aid provided by some programming languages (the languages that do have a comments feature) to assist the programmer in keeping track of what their code does.

Comments are documentation, not part of the code itself.

We distinguish between lines of code and lines of source files. Lines of code is analogous to number of statements in a programming language.

The binary output of a compilation procedure is not the code. In fact, it is not deterministic, since the code may be compiled in multiple different ways, each method of producing binary output requiring different numbers of instructions.

Re:"Real" lines?

[smellotron]

Source code is not written to be read by humans...

All of the generations of maintenance programmers following in your wake of write-only source code appreciate this attitude, I'm sure.

Re:"Real" lines?

[mysidia]

All of the generations of maintenance programmers following in your wake of write-only source code appreciate this attitude, I'm sure.

You're just confusing matters.

Maintenance programmers need to be able to figure out what source code does, but this is incindental.

Programs are written primarily for computer consumption.

You can have perfectly syntactic and legitimate source code that is unreadable to 99% of the population.

And you can have code that is readable by 99% of the population but isn't actually a valid working program or able to be made into a valid working program.

The former is more preferable.

Source code is not something humans can read, except for the small number of (exceptional) humans who are trained and have basic skills with the programming language code is written in.

If 'code' were meant for humans to read, the choice of language would have to be very different.

Re:"Real" lines?

[smellotron]

Source code is not something humans can read, except for the small number of (exceptional) humans who are trained and have basic skills with the programming language code is written in.

The same could be said for any technical field. The fact that 99% of the general population doesn't understand it has absolutely no bearing on this discussion. We're talking about the subset of people who can read and interpret source code.

If 'code' were meant for humans to read, the choice of language would have to be very different.

Do you put newlines in your code? Compilers don't need that. But I'm pretty sure it's a "swift kick to the head"-punishable offense to write your code without newlines in any organization.

Or, you could look at any number of programming languages designed with the human in mind. Python enforces scoping by whitespace. Perl has until and unless conditional constructs that are functionally identical to while and if. Whether or not you think they were successful, both of these are examples of programming language syntax catering to developers and not tools.

Source code is meant for compiler consumption. It's also meant for human consumption. It doesn't have to be either/or, it can be both.

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?

[TuringTest]

Have you heard of Literate programming? In that programming paradigm, documentation is part of the code.
Usage manuals are outside of source code by any definition, but think of doxygen / javadoc. Is it code what they generate, or not?

Re:"Actual" code?

[kesuki]

"By your standards, anything that makes source code human-readable should be counted as source code, including white space or even external documentation files!"

which would put us a 10 million lines of code instead of 6.5 million. I'm actually kinda surprised that they have that little amount of documentation in the source, there must be quite a learning curve if they only need one line of documentation for 3 lines or real code.

meanwhile, vista has "Windows Vista: more than five years in the making, more than 50 million lines of code."

only 5 times as much code as the linux kernel? or is that only counting new code?

how many lines of code is linux up to, if you add all the programs used by say, the knoppix 5.3 dvd? how many lines of code is you include the entire debian repository?

I like the linux desktop way better than the windows desktop, if business starts adopting linux, it's only a matter of time before real video games start supporting linux. no i don't count wine, or that fork of wine that tried to add support for windows only DRM and crap to get games to boot. i'm well aware of the multitude of time wasting games in linux. i do play some of them, they're nice but i don't waste that much time, at least not playing simple games.

Re:"Actual" code?

[glwtta]

Ok, now we just need a new word that means "the part of code that's not comments", because it's useful to be able to refer to that. You know, what used to be called 'code'.

Comments do not affect the function of the program, and therefore are not code. Just like whitespace (in most sane languages).

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:"Actual" code?

[smellotron]

I believe the word you're looking for is "statements."

Re:"Actual" code?

[hockpatooie]

You could, because counting the lines of assembled code would tell us exactly what we want to know: the level of complexity of the program that is being executed. It's just that the number of lines of C code is much easier to count, and anyway the relationship between the number lines of C code and number of lines of assembled code is fairly constant. It's a good enough metric for all practical purposes.

If your real concern is how hard it is for humans to maintain the codebase, then lines of code (with or without comments) is not such an informative metric in the first place.

Re:"Actual" code?

[bonch]

If the source code is written in assembly, then sure.

Re:"Actual" code?

[MadnessASAP]

Sure, why shouldn't it? It requires time from a programmer to produce it, it's definetly work and it makes it easier to maintain and update the code which results in better code. I see no reason not to include documentation and comments in most SLOC counts.

Re:Um

[RiotingPacifist]

Lets not forget that the NT kernel runs on ~4 arches linux runs on ~16, that has to make it bigger

Re:Um

[Cyberax]

After certain level modularity is harmful.

It makes little sense, for example, to make Linux so modular it can be run on your mobile phone and Roadrunner supercomputer without recompilation.

Re:Periods and Commas

[Ragzouken]

Using commas in a number is consistent with separating longer things into chunks, where using a full stop in decimals is consistent with separating two distinct parts.

Re:Tell us b0ttle

[corychristison]

(I'm not b0ttle - but I thought I'd comment)

I'm well out of school.

And my first thought when I read it was "I wonder how that compares to Vista and OSX."

Although, it would be for the reason of comparing the difference between an open kernel, closed kernel and semi-open kernel. My thought was: how does it's stance on openness affect the LoC metric?

I feel it would be a totally pointless observation, but would be insightful. Does closed source push stricter coding standards? Or does Open Source? Who knows...?

Unimaginable Code To Keep Up With

[dontgetshocked]

How can anyone keep up with this volume of code? As a simple vb coder myself I can't imagine wrapping your mind around this much code.

Approx 6,022,957 lines of code

[Anonymous Coward]

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.

Re:Approx 6,022,957 lines of code

[Anonymous Coward]

C comments begin with /*, not #.

Try again.

Re:Um

[zx-15]

And how is this different from functionality of modprobe tool that does exactly that?

Re:Periods and Commas

[Yvan256]

Actually IMHO it's better to split up big numbers with a space because you can use big, floating-point numbers in coordinates.

ex:
6 399 191, 96.4, 3.3

Re: so freaking what?

[Randle_Revar]

The Windows kernel might have a lot less, after all, it doesn't support nearly as many devices or architectures.

Re: so freaking what?

[Fri13]

Windows XP's OS code was about 6 Million LOC (Line of Code) while whole system had over 40 million LOC. How many LOC Windows Vista has in it's Operating System... mayby a 6-10 while the whole system might has over 40-60 million LOC?

We can really start believing what are the reasons for OS what is based to microkernel, while the monolith OS is HUGE to maintain...

Round numbers

[Danny Rathjens]

"Round numbers are always false."
-- Samuel Johnson

Re:Um

[Yfrwlf]

I was referring to two things here, not having to compile modules, actual real modularity on the binary level for true "modules", and also anything that's not a Linux module, 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. I don't think it's *all* modular, is what I'm saying, so any increase in that helps by making the kernel easier to work on because you can have definite targets and functionality, as well as making it easier to swap stuff in and out.

Re:Um

[Yfrwlf]

I was referring to two things here, not having to compile modules, actual real modularity on the binary level for true "modules", and also anything that's not a Linux module, 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. I don't think it's *all* modular, is what I'm saying, so any increase in that helps by making the kernel easier to work on because you can have definite targets and functionality, as well as making it easier to swap stuff in and out.

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!

Re:Um

[Yfrwlf]

Yes, because not having to require normal users (99% of users) to compile is outrageous! Then Linux might actually get adopted by the masses!

Wouldn't want that, especially if you're just using Linux to "be different". :P

Re:Huh, I didn't know the kernel was under CVS eve

[Randle_Revar]

apparently there was a bk to cvs gateway of some sort

Re:Um

[Fri13]

Linux was long time a macrokernel, including all drivers etc in kernel itself and loaded always in memory. After 2.2 it became a modular (in both cases it was monolith) so you could compile drivers etc as module. And then those modules were stored to disk, and not loaded to memory when the OS gets loaded to memory in start, what could lead very small memory usage, like only a few megs. And then when drivers etc are needed, they are read from disk to memory and be used. Bad thing was that every module was compiled to specific kernel version and the integration is very tight. And if you compile kernel, you need to compiler all the modules too. If one module or any other driver or OS part crashed, it brought the whole OS and software system down. So you needed to be sure that all the code what OS has, is checked and bug free. Now think that Linux has over 6 million lines of code (and how much are in drivers, what is most certain place to have a reason for crash!) so the OS is very HUGE.

But I think you are wanting OS what has a microkernel structure, where kernel itself is very small and all other OS parts are scattered to userland off from kernel, as OS servers, from there you could swap and compile all OS servers as they would be normal applications. Without need to compile kernel or other OS servers in same time. And if one OS server (driver, filesystem or network protocol) was compromised, you just could restart/replace that one without doing so for whole OS or whole software system. Because bug in driver affected just for the device driver itself, and not having possibilities to bring OS or whole software system down.

But you can always start wars with wich one is better OS structure, a Monolith kernel or a Microkernel based OS. Microsoft has used a microkernel structure in Windows NT and it continues using a microkernel structured OS in MinWin and on Singularity. So the OS should be very stable but we know that driver can bring the OS or the whole software system down very easily, even it should not be possible (in theory only?).

Multiple-level fail

[4D6963]

Since that many lines = approx. 125,000 pages, which = approx. 0.0175 terabytes

and "approx. 0.0175 terabytes" == approx 18 GB which explains why the kernel source's tarball weighs 48 MB. Yup, if you wanted to know how big the kernel source is you just had to look for it ;-).

Besides, I really wonder how you got to that figure, considered how code has little in common with classically formatted text anyways. Not to mention how 125,000 pages == 18 GB, I mean do you have 150,000 characters per page (2,000 lines per page?)?

Re:Multiple-level fail

[Trouvist]

A LOC is a Library of Congress.... That's how he got to that figure...

Re:Multiple-level fail

[isorox]

Since that many lines = approx. 125,000 pages, which = approx. 0.0175 terabytes

and "approx. 0.0175 terabytes" == approx 18 GB which explains why the kernel source's tarball weighs 48 MB.

That's compressed, Uncompressed the source is more like 270M

Makes sense..

[rickb928]

They must be getting paid by the line.... no, wait...

oh, they oustourced it to India by the line... no, wait...

They love writing code.

Yeah, that's it. Makes sense now.

Whoever they is.

Re:Periods and Commas

[Randle_Revar]

It isn't mismatched, it is just reversed from the US way of doing it. Mismatched would be "6.399.191, with 96.4%" or something.

However. I still think it is weird and cannot get used to it, despite preferring metric and EU data order.

Re: so freaking what?

[erc]

We can really start believing what are the reasons for OS what is based to microkernel, while the monolith OS is HUGE to maintain...

Except that I seriously doubt this number is LOC for the kernel itself - this undoubtedly includes drivers and other loadable modules. The number of LOC for the kernel itself, excluding loadable modules, is much less. Linux cannot seriously be called "monolithic".

Re:Um

[Yfrwlf]

No I'm not talking about that and I shouldn't have been so vague. Whether or not you have to compile modules or instead have binary compatibility so you can just plug them in has nothing to do with kernel space vs. user space and such. If you want stuff to stay in kernel space and make users put in their passwords to install stuff, so be it, but make stable APIs/ABIs so that good modularity exists and users can install drivers or configure their kernel without having to compile, something that should be done once by the developers unless other users/devs want to see their code and want to compile stuff themselves. Modularity means that devs can more easily target certain areas and divide and conquer work, and it means having more points that have stable APIs and ABIs for greater flexibility and just, an easier Linux experience. What if I don't want to compile a patch, what if I just want to throw it in there, and I don't want to have to rely and wait on a distro repository compiler to do it for me but instead get it directly from the source? I'd rather get my kernel updates from the source, as well as all my other software, instead of being walled in unless I go compile something myself.

Not to mention all the electricity it'd save from having only a few computers in the world doing the work to compile. And...um...they use trees for firewood, so, save a tree! Because all good movements should end up saving trees. ;) But seriously, recompilation is really inefficient, so it shouldn't be required by an OS, you could do better things with your CPU like the @Home projects. :P

10 million for a kernel?

[nurb432]

Christ.. thats just silly. What ever happened to people being efficient?

How much legacy garbage is still floating around in there?

Re:Um

[Cyberax]

Why? I have not compiled my own kernel for about 2 years now without any problem.

Ubuntu provides a nice generic kernel which is suitable for 99% of desktop workloads.

Hmm, upwards of women...

[melted]

Personally, I prefer downwards of women, but if only upwards are available, that's fine, too.

Re:Um

[ianare]

Oh because you think that 'most user friendly OS' - OSX doesn't need a recompile for iPhone vs laptop use ?
And did only having one architecture hinder Windows from taking over the world (yes I know it supports 2 variants of the same now) ?
Besides 99% of linux _desktop_ users do not _need_ to compile anything. I certainly have never had to do so for regular use.

Now for an admin ... well that's part of the job description.

Re: so freaking what?

[abdulla]

Linux cannot seriously be called "monolithic".

Well it can't be called a micro-kernel. And the notion of a "hybrid-kernel" is a joke. It's squarely in monolithic town.

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:linux kernel getting bloated

[pjt33]

10. Embossed, signed paper Certification of Live Birth -- Not Released

Are you trying to imply that he was born dead, and is some kind of zombie hitherto unknown to man? That would certainly explain why he hasn't released his medical records.

Of course, not being a complete raving loony would also be a fair reason for not releasing your medical records. Has your expectation of the privacy celebrities should be afforded sunk so low?

the worsest OS

[Alomex]

Back in the day when Windows NT first reached over 3.5 million lines of code this was used by Linux fanbois as proof positive that NT was a bad operating system. So I guess this means that Linux is now three times worse.

Re: so freaking what?

[colmore]

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

As Edsger Dijkstra would say

[mysidia]

"If we wish to count lines of code, we should not regard them as lines produced but as lines spent." --Edsger Dijkstra

Bad title! Naughty!

[beav007]

the real number of pure code lines: 6.399.191

So, in fact, it's not 10 million lines of code at all. It's just 10 million lines. Wooooo.

bfws

[jonaskoelker]

I would have guessed it to be all the Whitespace in the C and assembly. That's a language that can really brainfuck you. A real gem, a perl I tell you ;)

News?

[Samah]

Why is this news? Single commercial applications can have more than 10 million if they're complex enough. I would EXPECT the Linux kernel to have this many lines of code (or more) given what it does and how long it's been in development.

Re:News?

[belg4mit]

Don't forget the number of architectures it supports

Re:News?

[Samah]

Yeah that was pretty much my point. I'm surprised that it's not 15 or 20 million already, so I don't see why 10 million lines is such a milestone.

Re:I know this should be obvious, but...

[the_raptor]

1) It is hard. Most programmers can't beat out the compilers auto-optimisations.

2) A lot of low level hackery to optimise your code, often makes it unportable and unmaintainable.

3) Hardware is massively cheaper than programmers hours. This is the whole point of languages like Python.

4) Most of the RAM bloat in modern systems is for the fancy GUI. Reducing the RAM usage in that case normally means increasing the CPU load. RAM is easier to scale then CPU.

One word...

[NateTech]

Bloatware.

Re:this is news?

[spazdor]

I care because up at the top of this website is the tagline "Stuff that matters."

This is the biggest non-headline I've ever seen.

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: so freaking what?

[AlphaGremlin]

Personally I thought the news was that no one knows what 0.3% of the linux kernel is written in.

Most likely the missing 0.3% is makefiles and miscellaneous scripts.

No. What people are trying to do...

[symbolset]

Is get a computer to do stuff like the first world does, with a third world power infrastructure.

Hint: They get their electricity from carbon fuels. We don't want them to build out their power infrastructure because we're fond of our Gulf Stream.

Capiche?

Cans of Jolt

[symbolset]

The PHB problem is that they must have metrics to measure so they can list their datapoints in Excel and turn it into a nice Powerpoint slide.

I am SO glad Linux is invulnerable to this sort of attack.

Re:Um

[symbolset]

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

As we seek the common market it's best not to mention this whole "compiling" thing. Sure, people can do it, but they don't have to and it has the market appeal of Vista. It's best to leave references of it to howto pages and geek sites where optimization is key and proficiency is assumed. Slashdot is not quite that, yet.

Why has nobody said..

[symbolset]

'Tis the dream of each programmer

Before his life is done,

To write three lines of APL

And make the damn thing run.

The parts of the kernel that could be converted to APL would reduce its size by 90%.

OTOH, APL bests perl in "write only" language contests.

Re:Time to switch from Linux-bloat-ware to Minux

[itsybitsy]

Ok, so those who can't handle the truth suppress the opinions of those who can handle the truth and a better technology. I guess the lemmings jump off the monolithic cliff together... I'll go the other way... all the best with your choice...

Re:No. What people are trying to do...

[p0tat03]

Hint: They get their electricity from carbon fuels.

We also get most of our power from carbon fuels...

Not to mention that there are plenty of extremely low-power computers that have respectable performance numbers...

Re:Um

[master_p]

To be fair, you don't need to compile a custom NT kernel, you only need to write new drivers, of which the VxD portion will be loaded into the kernel space. You would only need to update the NT kernel if you wanted to change core things like how the virtual memory system works, but then you would have to change the Windows API...I think it's best if that task is left to Microsoft (who, despite the mocking from /., they have bring out a very decent kernel...the NT kernel has not been reported to crash (not the drivers, the kernel!) for a very long time now).

Re:Um

[MadMidnightBomber]

After extensive experience of looking after Windows, I've decided that all NT kernels are custom kernels - you just don't know in what manner it's been customised, or by whom.

Drivers?

[AaronLawrence]

Isn't most of it just drivers?
In which case it's hardly exciting as it could triple in size and the actual kernal features be exactly the same.

Re: not a "near miss" ?

[Zoxed]

> Linux has already had a near miss back in 2003

I am not sure you could call it a "near miss". It was detected automatically during a routine check (you would not say a aircraft "nearly crashed" if a fuel pipe leaked during a pressure test in the maintenance hanger ?).

there is

[Chutulu]

the proof that Linux is a bloated piece of shit

In My Day...

[airship]

The Commodore 64 Kernal* was 8K and lived in ROM... and we LIKED it!**

*Yes, Commodore really spelled it that way.

**We liked it because the C64 booted in about 2 seconds! :)

Re: so freaking what?

[Fri13]

I did not say that Windows NT microkernel was about 6 million LoC, but the Windows NT OS. Windows NT OS use microkernel, so the OS is the kernel + OS servers in userland. The Windows NT microkernel might have 50 000 - 200 000 LoC while the whole Windows XP Software System has over 40 million LoC

50 000 - 200 000 Microkernel LoC
~6 million OS LoC
40 million Software System LoC

Linux OS has now over 6 million lines, it includes all drivers etc. The kernel itself, without any drivers etc, might be lots of smaller itself. But the whole Linux OS distribution like Fedora, has over 200 million LoC

~6 million OS(monolith kernel) LoC
150 - 250 Million Software System LoC

And Linux is cery seriously a Monolith, but it is modular and not macrokernel.

get me the ram-hog!!

[tempest69]

Ram is cheap.. dirt cheap. I want to use it by the bucket. I dont want my hard drive to do any reasonable seeking. I want windows to boot by just raw-loading the first 2 gigs of HD into memory then insta-booting. 30 seconds on a reasonable box.

I want my apps to run in a sandbox, where they cant break jack.. no matter how malicious they are. I want the box to be absurdly robust. And I want it to work as smooth as silk, no weird jerkyness, no pinwheel that keeps spinning for no apparent reason.. no slow response to the keyboard-- where 8 seconds go by without so much as the slightest feedback.

Get me a system that isnt a dog, and I'll pay for the 32gigs of ram. It will be money well spent.

Storm