A tech writer who still counts on her fingers and toes, tries to wrap her head around the size of the Linux kernel, and wonders when its weight will cause it to crash through the Earth’s mantle. She’s being silly, of course. Or is she?
An interesting factoid caught my eye in an article published by Opensource.com this morning. The article was one of those interesting and easy-to-read listicles that many websites — even FOSS Force — likes to run occasionally called 9 Lessons from 25 Years of Linux Kernel Development, and the item that caught my attention was eighth on the list, under the heading, “The kernel shows that major developments can spring from small beginnings.”
“The original 0.01 kernel was a mere 10,000 lines of code; now it grows by more than that every two days. Some of the rudimentary, tiny features that developers are adding now will develop into significant subsystems in the future.”
10,000 lines of code added every other day? Really?
Let me do some math in my head, with a lot of rounding to make it easier. There’s no need to be too accurate here. That would be 5,000 lines of code added every day, 50,000 every 10 days or something slightly north of 200,000 lines added every month. That comes out to something over 2.4 million new lines added each year. In the long run more than that, I figure. If I understand how the math of code development generally works (admittedly, this is a gray area for me), as we keep adding lines of code, the number of lines that get added on a yearly basis will also increase.
Is this sort of growth inevitable, I wonder, and just part of the work of keeping Linux up to date? What about bloat? Is it hypocritical to point fingers at bloated software in this case? Most of all, I wonder, is this sort of code growth even sustainable?
With the current kernel size approaching 20 million lines, that means that by 2021 we can expect that number to grow to somewhere around 30 million. More, if you factor in the growth of the growth rate factor. And that’s just the kernel. It doesn’t even begin to account for all of the other stuff that makes a modern Linux distribution — both GNU and not GNU — which I’ll bet is also probably growing.
This adds a whole new meaning to the notion that “software is eating the world.”
I’m no computer scientist (I’m sure most of you have figured this out already), but I assume that most of these lines of code will never even be read by my computer’s hard drive. They concern all sorts of hardware I’ll never own, different CPUs, routines that the software on my computer will never need and the like. But still, that’s an enormous amount of growth — at least for my pea sized brain to comprehend.
How long can this continue, I wonder. How long until we reach the stage where Linux is just too big to be maintained? Or will we be able to work with the system even when the number of lines of code draws near to the number of stars in our galaxy?
I don’t know. Can somebody tell me?
Meanwhile, I’m taking a lesson from “Gremlins.” I’m keeping my Tux plush toy dry and will never again feed him after midnight.
Oh crap, I forgot about the GNU…
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
probably more like 10,000 insertions/deletions a day
https://stackoverflow.com/questions/9013786/what-are-insertions-deletions-in-git
The linux kernel is getting to be about as big as some BSDs minus a toolchain/compiler and C++ library.
When will it reach a BSD + C++ library + toolchain?
netbsd, if you exclude external/ (contains multiple toolchains) and xsrc/ (Xorg stuff) is 14.5 million lines of code, and 7.5 million is the kernel.
Oh no, soon there’ll be no room for anything but the Linux Kernel on my computer!
most of this new code should be drivers, which are mostly selfcontained modules that the kernel itself does not depend on. (so they don’t add complexity to the kernel itself, they just live in the kernel space)
greetings, eMBee.