The Linux Kernel Has Grown By 225,000 Lines of Code This Year, With Contributions From About 3,300 Developers (phoronix.com)

Here's an analysis of the Linux kernel repository that attempts to find some fresh numbers on the current kernel development trends. He writes: The kernel repository is at 782,487 commits in total from around 19.009 different authors. The repository is made up of 61,725 files and from there around 25,584,633 lines -- keep in mind there is also documentation, Kconfig build files, various helpers/utilities, etc. So far this year there has been 49,647 commits that added 2,229,836 lines of code while dropping 2,004,759 lines of code. Or a net gain of just 225,077 lines. Keep in mind there was the removal of some old CPU architectures and other code removed in kernels this year so while a lot of new functionality was added, thanks to some cleaning, the kernel didn't bloat up as much as one might have otherwise expected. In 2017 there were 80,603 commits with 3,911,061 additions and 1,385,507 deletions. Given just over one quarter to go, on a commit and line count 2018 might come in lower than the two previous years.

Linus Torvalds remains the most frequent committer at just over 3% while the other top contributions to the kernel this year are the usual suspects: David S. Miller, Arnd Bergmann, Colin Ian King, Chris Wilson, and Christoph Hellwig. So far in 2018 there were commits from 3,320 different email addresses. This is actually significantly lower than in previous years.

Comments

Re:Equality

[Anonymous Coward]

March on, comrade! The radiant socialist future is just over the next hill!

doesn't seem surprising

[thePsychologist]

This doesn't seem surprising, given that new architecture comes out all the time. What's great is that this amazing piece of work is still FLOSS, powering my Macbook as I type this comment.

Re:doesn't seem surprising

[Anonymous Coward]

I don't know which is worse - the guy posting above talking about having sex with his mom, or Linux on a MacBook.

The cake is a lie

[Anonymous Coward]

Editor david, I can appreciate what ur trying to do. But stupid is stupid. Cant change that

Only 19.009 authors?

[Anonymous Coward]

And who accounts for the 0.9% of an author?

Re: Equality

[Anonymous Coward]

No, he has to come back inside. The Hills lately are filled with squatters, both day and night.

Lines of code

[SCVonSteroids]

Why do we measure in lines of code? Serious question.

Re:Lines of code

[Archtech]

What's a good alternative? Serious answer.

Function points?

At least LOC gives us a rough estimate of how much work has been done writing source code. Of course it may be bad code, or completely wasted, and of course it must be calibrated by the language used.

The problem IMHO is not the use of LOC but the foolish assumptions some people make based on that metric.

Re:Lines of code

[Anonymous Coward]

Because we are lacking better ways to measure code.

Sure, lines of code doesn't have to be a good thing and neither does binary size, but those are easy to quantify.
Would you rather that we used electro-psychometry to measure it?

Re:Lines of code

[ShanghaiBill]

Why do we measure in lines of code? Serious question.

LOC is an important metric, for quantifying both progress and complexity.

The mistake is assuming that more is better.

Re:Lines of code

[Kjella]

Why do we measure in lines of code? Serious question.

Lack of a better metric? Though at this level of abstraction I think classifying a project as small = 1 kLOC, medium = 10 kLOC, big = 100 kLOC and huge = 1000 kLOC project works just fine. I would think the number of maintainers you need scales pretty linearly with LOC. But it doesn't mean it's a useful measure of productivity....

Re:Lines of code

[QuietLagoon]

... Why do we measure in lines of code? Serious question. ...

Some metrics have as their base the number of lines of code. In and of itself, LoC is pretty meaningless. Other views which use LoC, however, can be quite useful.

Re:Lines of code

[Anonymous Coward]

Why do we measure in lines of code? Serious question.

It is easy to count newlines in C.

In Javascript, it's the size of the compressed script file size.

Re:Lines of code

[fahrbot-bot]

Why do we measure in lines of code? Serious question.

LOC is an important metric, for quantifying both progress and complexity.

And yet, LOC doesn't necessarily quantify either progress or complexity.

Re:Lines of code

[Anonymous Coward]

For the same reason that researcher productivity is counted in published papers: laziness.
It's easy to count, now code quality, or paper quality for the matter, is much harder to measure.

Re:Lines of code

[Anonymous Coward]

That is nonsense.

It's like saying one should count the bytes of a compiled C program.

Re:Lines of code

[Zero__Kelvin]

The question isn't Why measure in Lines of Code, but why not put those numbers in a context. It is necessary to understand how LOC increase does, and more importantly perhaps, doesn't increase overall complexity, vulnerability / attack surface, etc. I don't think there is any intention to deceive here ... I just think the author forgot how much they know that the target audience doesn't.

Re:Lines of code

[arth1]

What's a good alternative? Serious answer.

Function points?

At least LOC gives us a rough estimate of how much work has been done writing source code.

Z factor is a better one - the size of the code after being fed through compression (like compress, giving .Z files). Large amounts of extra spacing or unnecessary line breaks won't be factored in, while code originality gives a higher score than copy/paste jobs.

Re:Lines of code

[AlanObject]

Why do we measure in lines of code? Serious question.

I would like to know a decent alternative. For the past 20 years whenever I was involved in a contractual transfer of intellectual property of software I would invariably get asked "how many lines of code?"

Generally the question is not too hard to answer as long as you don't get too picky. After all we are talking about a "find" command piped into "wc" on various checked out directory trees. Who knows what percentage of that actual compile-active source code versus everything else. The legal and accounting and M&A departments never seem to think to ask.

To make things more uncomfortable for the software engineers who just want to be honest about it, more often than not the seller wants to include the lines of open source in the total because that is much, much bigger. Of course. One example: last century I worked with an embedded (Linux) product selling pretty well and the unique, proprietary code was about 300,000 lines or so. Include the kernel and utilities compiled and bundled in and you ended up with about 3,500,000 lines of code. Guess which number was used to price the sale.

I spent some time trying to think of some way to vault over this kind of BS but I never got anywhere with it and ceased trying. They don't want to hear it.

At the end of the day it doesn't really matter. What matters is the revenue stream the resulting software generates and the customer base it has. What they really are asking is how hard it is to duplicate the software by, say, some cheap programming team in the third world. That in fact is a forever unknowable quantity but you have to give them something to believe in that they can use to convince the buyer to sign the check.

Re: Lines of code

[jd]

Lines of code tells you how much work was put in.

The ratio of lines of code to code blocks tells you how maintainable the code is.

Defect density tells you the quality of the code.

A triple of these would give you a reasonable analysis.

Re:Lines of code

[Anonymous Coward]

That's what I said i the sentence you chose not to quote. You're a real fucking asshole retard for being such a bitch.

Re:Lines of code

[Anonymous Coward]

It might be a better one.

However, it also favors using unnecessarily long variable and function names and choosing the most original method to solve a problem rather than the best.
Instead of using for loops in two places, us a for loop in one and a while in another to make it less compressable.
Alternate placing the bracket directly after the if clause, with a space between or on the next line to make sure that the originality of the code is higher.
Maybe include iso646.h and mix in there somewhere to make the code a bit more verbose.
Heck, you can even use the bitand macro to get the address of variables if you really want some extra originality.

Good code should compress well.

Re: Lines of code

[Anonymous Coward]

That's crazytalk. 5TB binary tells you nothing!

Re:Lines of code

[AHuxley]

The idea was for small amount of code to do DOTADIW, or "Do One Thing and Do It Well."
That would see a lot of really well understood code working hard to make a really great OS.

Re:Lines of code

[Pseudonym]

Because that's what diff measures.

Re:Lines of code

[gTsiros]

considering that the best code is the one you don't write, i'd say LOC is a horrible, horrible metric.

at work, our main product is roughly 2 million LOC (not counting blank lines, lines with only comments, preprocessor statements...)

considering that so far any class i've tried to simplify was down by *at least* 95% (not exaggerating, in some cases i straight up *removed* classes because they were duplicated), i'd say the actual code is less than 100k. Possibly on the order of 10k.

Re:Lines of code

[Anonymous Coward]

LOC is an easy metric, for quantifying both progress and complexity.

The mistake is assuming that more is better.

FTFY.

Re: Lines of code

[Anonymous Coward]

Lines of code tells you how much work was put in.

No it doesn't.

LOC != kernel bloat

[Zero__Kelvin]

An important caveat here is that increase in LOC count does not mean a linear increase in loaded kernel memory usage. For example, for every new driver each line of code is counted, but that driver may or may not compiled in or loaded as a module. If a driver for wireless card X is 1200 lines of code, but your system doesn't have that card and it was compiled as a module, then zero of those added lines of code generated machine code get loaded at runtime .

There are more than 1000 .config options, and over 30 supported hardware architectures, so your code mileage *will* vary.

Re:LOC != kernel bloat

[Anonymous Coward]

Also, code which actually has a purpose isn't "bloat" in the first place. I get the feeling that the person who used the word either doesn't know the meaning of it, or is trying to be inflammatory.

Re:LOC != kernel bloat

[Anonymous Coward]

Hopefully most of those lines are comments anyway.

Re:LOC != kernel bloat

[Anonymous Coward]

An important caveat here is that increase in LOC count does not mean a linear increase in loaded kernel memory usage. For example, for every new driver each line of code is counted, but that driver may or may not compiled in or loaded as a module. If a driver for wireless card X is 1200 lines of code, but your system doesn't have that card and it was compiled as a module, then zero of those added lines of code generated machine code get loaded at runtime .

There are more than 1000 .config options, and over 30 supported hardware architectures, so your code mileage *will* vary.

Since when has “kernel bloat” strictly meant kernel memory usage?

Re:LOC != kernel bloat

[deathguppie]

the Linux kernel is a mature piece of code. The amount of changes to core architecture should be limited to planned events and take years to mature to the point of inclusion. What we are looking at is just the amount of interest in making sure that the Linux kernel is being maintained at a prodigious rate so that we can wake up knowing that our bugs are being fixed and our security patches are on time. If there are people out there thinking that any amount of "lines of code" are some kind of developmental feature in the Linux kernel without a subsequent announcement they are deluding themselves. This is just to let people know that the machine is working fine.

Re:LOC != kernel bloat

[Zero__Kelvin]

Absolutely, my brother!

I can fap to this

[Anonymous Coward]

Thanks guys!

captcha: thumbing

How many vulnerabilities?

[Anonymous Coward]

Monolithic kernel?

Re:How many vulnerabilities?

[Anonymous Coward]

None compared to you, apparently, since all of you seem to be one huge vulnerability.

Linux jumped the shark years ago

[Anonymous Coward]

Never had the critical mass to win over desktop users (real workstation desktops, not hobbyists). Now it's just a bunch of change for the sake of change, plus a ton of meltdown/spectre bloat.

It's too bad, it could have been a contender had the chips fallen their way and they had make a few critical decisions differently. Now with the systemd malware being stuffed down everyone's throat, it's assuredly game over.

Re:Linux jumped the shark years ago

[Anonymous Coward]

Of course it's nonsense, he's wrong even when he's right. Let's, however, not pretend everything is sunshine and roses in Linux-land,because it sure ain't.

There is for instance, plenty of change, but it's not change for the sake of change. It's for the sake of invalidating knowledge which is out in the field, so Redhat can make their money on "support" and "training", while being "leaders" thanks to being the largest company and having the resources to continually rewriting "Linux" into "Redhat", and forcing everyone else to chase their tail lights.

Want examples? SystemD, PulseAudio, Firewalld, etc, etc. None of which are "better" in any objective way than what they replaced -- systemD doesn't boot fast than the old system for instance, despite that being one of it's supposed selling points -- nor do they actually fix the problems they are sold to us as fixes for; most of the time they aren't even trying to fix them on the right level, but act like some band aid on top of a festering boil, with predictable results.

Other troubling signs include how Intel tried --very hard -- to shove all x86-cpu's under the Meltdown-bus. How much crap like that goes on but never reaches the public, I have no idea, but wouldn't be surprised at all if Intel had their own version of Nvidias game-not-works. After all they've already got caught outright sabotaging AMD when using ICC. Intel paid gatekeepers on critical projects? I wouldn't trust them too far.

Linux is good, but that doesn't mean it's perfect or that there aren't potentially pretty big problems inherent with it.

Re:Linux jumped the shark years ago

[Anonymous Coward]

1) Plenty of real works station users use Linux.

Yes just like 'plenty' of smartphone users use Meego.

2) "Change" for change sake? Like what?

It's more at the OS level than the kernel level but there are hundreds of distributions and the Linux community in general is rife with NIH syndrome.

4) "Could have been a contender"? Could have? What is running most of the worlds server infrastructure? What is underneath Android?

Yes the FOSS method works for things you don't see or care about, like the Linux kernel. Anything FOSS surfaces to the user is an immediate failure which is why by and large Linux operating systems never captured any significant share of the desktop and why Android was built atop it but abstracted away such that you could replace the kernel with no impact on users.

5) Systemd is a not malware. Besides it's also not the Linux kernel, which happens to be what we are discussing here.

Right but that is the way Linux is surfaced to the user in the desktop environment and it is horrendous so you can't really just say "oh we don't care about that, we're only interested in the kernel".

Re:Linux jumped the shark years ago

[Anonymous Coward]

1. Your own example, what does that say about all the users of Windows smartphones?

2. And this is not true about Windows and the applications running on it?

4. And this is a failure of Linux? I get feeling you don't get out much and know very little about how markets and average humans tick.

5. You're confusing your Stockholm syndrome with facts. Sorry.

Do us all a favour and shut up before you embarrass yourself further.

Well, crap hardware stays crap hardware.

[Anonymous Coward]

At least the other guy had sex with a human.

And not with some jewelry with some really low-quality hardware inside. (Which will be fixed with the 2019 models. Them containing hardware that is. An iridescent shiny mirror surface will be much simpler, and the difference won't be noticed by the users.)

Source: Louis Rossmann videos on YT. ;)

Re:Well, crap hardware stays crap hardware.

[Anonymous Coward]

You're showing your sheepiness by following louis on that kind of reasoning.
Congratulations, a sheperd will soon come by your house to pick you up and lead you to slaughter.

Embedded = Fubar

[Anonymous Coward]

If/When you look at the linux embedded scene, you'll notice that there is way too much duplication of functionality going on.
Then you have to look at the linux embedded kernel forks which haven't been integrated into the mainstream kernel, and you find even more duplication going on.
It is horrible, and it is getting worse every day.

Also, the newly integrated Cryptocoin miner for the x86 SMM EC is a real LOC hog, but that's what you get when you need to hide its functionality.

All in C?

[Anonymous Coward]

Is all written in C by men? That's horrible!

Re: All in C?

[Anonymous Coward]

Well, the compilers used to take the C source and turn it into binary for the computer to run. However, since "binary" now is non-PC all the CIS crew and overly offended changed the compiler to produce non-binary code, which is why it's so horrible. We need to Make Linux Great Again, rip out all the systemd bullshit, make kilobytes = 1024 instead of 1000 and we'll make all the LGBTQXYZ$#?%0-9's pay to fix it.

#MLGA

Fallacious argument is fallacious.

[Anonymous Coward]

Something too bad to be acceptable does not become acceptable by virtue of there not being any "other" choices.

Because if unacceptable choices are OK, all the other ridiculous ones are also acceptable, and your argument does not support preferring this ridiculous one.
And if unacceptable choices are unacceptable, as you suggest, this one is still unacceptable.

You could as well count the cups of coffe consumed. It would be just as useful.

Unless you have a proper metric for difficulty, to multiplicate with time, you simply do not have a metric for amount of work done. Deal with it.

How many bugs in, say, 10,000 lines of code?

[QuietLagoon]

What's the rate of bug occurrence per 10k LoC in the Linux kernel? I'm less concerned about additional kernel bloat than I am about additional kernel bugs.

Re:How many bugs in, say, 10,000 lines of code?

[Anonymous Coward]

I have no idea.

You could take a look and count them for yourself if you like.

The code is here for your convenience https://github.com/torvalds/linux/tree/master/kernel

Re:How many bugs in, say, 10,000 lines of code?

[Anonymous Coward]

For example, this: https://scan.coverity.com/proj...

They state 0.45 defects/kLOC. Of course, they won't "find" all defects... and there might be some false positives in there. But you get the ballpark.

Use your favourite search engine (hopefully not Google and its ilk).

Kids, these days. When I was young, I queried Altavista with telnet. Tsk, tsk.

Re:How many bugs in, say, 10,000 lines of code?

[Anonymous Coward]

I'm calling it -- FAKE NEWS!
I followed your "coverity" link and it states that C/C++ is the kernel's language!
There is NO C++ in the kernel!!! Mildly kidding, of course, but I really hate it
when the two are grouped together - it's like saying that since python shares
some C constructs, it's okay to call / python should have been named cpp.
No we all know where that would have led...

CAP === 'playable'

Re:How many bugs in, say, 10,000 lines of code?

[phantomfive]

They state 0.45 defects/kLOC. Of course, they won't "find" all defects...

They won't find most defects.

But you get the ballpark

Not really because the kernel developers know how to avoid the kind of bugs Coverity scans for (Coverity has been haranguing them over it for nearly two decades now).

Re:How many bugs in, say, 10,000 lines of code?

[Lost Race]

If kernel code is like most code, and it probably is, there is about 1 bug per line of code. So 10,000 or so.

Bloatware?

[Anonymous Coward]

Sure sounds like "Bloatware" but that only happens to closed-source commercial software, amiright?

Re: Bloatware?

[Anonymous Coward]

You do realize you can turn on and off different features of the kernel right? So they give you the whole kitchen, but it's up to you to pick out what appliances you want.

Also, they got rid of millions of lines of code that were no longer needed.

But you must be right, a kernel that's been around so long and supports so much must suck and be horribly bloated.

Re:Bloatware?

[cyberchondriac]

Latest release name for Redhat AES8: Bloaty McBloatface.

Just poking fun. Linux is still quite lean compared to most OSes.

and msmash is still on her knees..

[Anonymous Coward]

really,
after 3hundred billion trillion quintillinon lines of code
she whom shall remain prone in any and all CODE COMMIT situations.

Lets go running to Linus for his comment on the atrocity of the situation, and please get her some knee pads.
 

But how many contributors were women?

[Anonymous Coward]

This is the key issue.

Re: LOC != kernel bloat. FALSE!!

[Anonymous Coward]

The kernel is bloat. Most of the new code should be outside and indenpent of of the kernel. Look at ZFS it is outside of the kernel and proves that NO file system code is needed in the kernel except for boot file system so the kernel can load first needed modules like a FS so rest will follow.

Break the kernel up and we can get to the point of true replace parts and modules. Even having 2 or more of the âoesameâ FS so you do not have to do Big Bang upgrades.

SMALLER THAN U.S. TAX CODE

[Anonymous Coward]

And it costs a damn site less.

Re: LOC != kernel bloat. FALSE!!

[Anonymous Coward]

It's fine. We can just wait for SystemD to take it over and then everything can be binary and better and faster.

Kernel code or drivers?

[Gravis Zero]

What really matters here is if we are talking about if this is a lot of code that has a direct effect on the functionality of all kernels or if this is really about code for specific kernel drivers. Last I read, the kernel core was like 2M LOC while kernel drivers made up 31M LOC.

Re:Kernel code or drivers?

[Anonymous Coward]

Yeah I wondered this, I was surprised when I learned about how drivers are counted in kernel projects, not just talking about Linux either, I submitted one to FreeBSD. They are often quite separate.

So, these contributors....

[dwywit]

is Sievers still banned?

Re: LOC != kernel bloat. FALSE!!

[Zero__Kelvin]

Congratulations ... You win the SFC award!

Can you say bloat?

[Anonymous Coward]

This is just insane.

Uncontrolable Bloat

[aberglas]

If those statistics are really true. Over 200,000 NEW lines in one year in an existing, complex system is as unmanageable as 3000 contributers. As products age, the rate of additions goes down as things have to be integrated into a complex system.

Sure, Linux is not actually as monolithic as described. But a bug in any one of those lines could bring down the whole kernel.

It is a credit to skill of the maintainers that they can make this work. And a debit that they try.

Re:Uncontrolable Bloat

[fibonacci8]

You're one of those people that compiles kernels with every available option enabled, regardless of the use case, aren't you?

Re:Uncontrolable Bloat

[phantomfive]

But a bug in any one of those lines could bring down the whole kernel.

Most of it is drivers, and most of those drivers are for devices not running on your computer, so if there is a bug, it will be in a code path that is impossible to reach on your system (are you using JFS?). The core kernel is a lot smaller.

Re:Uncontrolable Bloat

[Anonymous Coward]

Which begs the question as to why so much of those drivers needs to be in the kernel.

Re:Uncontrolable Bloat

[phantomfive]

It really doesn't beg any question, you are not writing clearly. If you want to know why little-used drivers are in the kernel, the answer is that even if only .05% of the users actually need it, and someone is willing to maintain it, then that is a good enough reason to put it in. The kernel is well architected so adding another driver won't affect the quality of the other parts of the code.

5 commits per day

[mapkinase]

Linus Torwalds commits 5 commits per day

Yup. Moving to L4

[meburke]

As a person who's been doing UNIX since 1984, ATT SVR3.2 was my favorite, although I've used other variants. I'm tired of Linux crap. I'm tired of systemd and the systemd wars. I'm tired of having to learn nuanced differences in various distros just to do basic, common, tasks. I'm tired of package repositories that suck when it comes to good maintenance (although they are still better than rpm hell). I'm tired of half-baked security measures that are badly designed and beyond human understanding. (IMO, admin should be a straight-forward set of tasks where doing one thing doesn't break 10 others.)

I'd rather move to seL4 and have to write drivers for the few things that I use which aren't totally implemented yet. Luckily, I am old enough that I don't have to work for anyone who doesn't agree with me, and I still have skills current enough to make the change for me and my clients.

Linux is going to drown in its own sh*t.

Re:Yup. Moving to L4

[Anonymous Coward]

FreeBSD seems to be home of the old timers who missed the good old days and missed the old Unix way of things like ABIs and excellent documentation with the Handbook and the CVSup examples (if they are still there)

Re:Yup. Moving to L4

[Bengie]

FreeBSD is still maintained by many of the original AT&T Unix, BSD, and Solaris engineers. Some have taken more high level project management positions, but quite a few are still in the trenches writing code.

Re:Equality

[Anonymous Coward]

Are half of those lines made by women?

No, Linus was an asshole to them.

Line counting

[peretto]

And how many lines did they removed? :)

Re:Line counting

[sabbede]

2,004,759

Totally massive fail!!!

[LostMyBeaver]

25 million lines of code is inexcusable at any level.

The amount of code required to make Linux work is not even a million. Let's assume you can get every feature of interest into a LOT less than that and then depend on modules for everything else.

Consider that the Linux Kernel as it stands today is one massive repository of trash on trash on trash on something less trashy.

Linus mad Linux and he made Git and Git has things like submodules and there are things like GVFS as well in some environments. Why not scale the kernel back to bare minimums and then link modules in separate repositories and make something like a package manager to tie it all together? I mean seriously, there is not now or will there ever be a suitable excuse for such a horrible monstrosity as the Linux kernel.

If Linus is taking a break... maybe it's time to just boot him from the whole thing and get someone in who is more focussed on cleanliness and organization. For example... let the Linux foundation toss the new maintainer $100,000 per million lines of code stripped from the kernel and offloaded into an external project. Rebuild the make config system so that it works based on a series of features and git URLs instead of being one gigantic pile of define nastiness.

I think it's time for a real change to Linux.

BTW... I don't think it's ever possible without a complete rewrite, but it's time to clean up the headers. I mean seriously... have you seen the pile of shit in the linux header directories these days? Github as well as others won't even let you see the directory listing anymore. What about multi-thousand line headers which contain so much crud you can't even read them anymore?

I think Linux is awesome in its scale... but if you've ever written a kernel module, you'd know how severely horrible the current design ... or lack of design is.

So, they're counting documentation?

[sabbede]

The summary seems to indicate that part of those changes are in documentation, which is not code.

Warning!

[Anonymous Coward]

225,000 new lines of code =
systemd CRASH! CRASH! CRASH!