Slashdot Mirror
Linux Is the Largest Software Development Project On the Planet: Greg K-H (cio.com)
sfcrazy writes: Greg Kroah-Hartmant, the Linux superstar, delivered a keynote at CoreOS Fest where he gave some impressive details on how massive is the Linux project. Kroah-Hartman said the latest release (4.5) made two months ago contains over 21 million lines of code. More impressive than the amount of code, and what truly makes Linux the world's largest software project is the fact that last year around 4,000 developers and at least 440 different companies that contributed to the kernel. Kroah-Hartman said, "It's the largest software development project ever, in the history of computing -- by the number of people using it, developing it, and now using it, and the number of companies involved. It's a huge number of people."
The VMS operating system was estimated to contain over 25 million lines of code, and that was measured over 10 years ago - I'm sure it's quite a bit more by now.
There is no God, and Dirac is his prophet.
The VMS operating system was estimated to contain over 25 million lines of code, and that was measured over 10 years ago - I'm sure it's quite a bit more by now.
This is just the kernel. But most of it is arguably "not" kernel code... it's drivers. This is directly addressed in TFA:
All versions of VMS and OpenVMS together come nowhere near to running on as many different hardware platforms as Linux, so it would be shocking if Linux's drivers weren't massive in comparison.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I nearly fell out of my chair when I read your LKML post claiming that the 2.2.x/2.4.x kernels were more stable than they are now. I'm guessing you either weren't involved with Linux back then or have a short memory.
Here is a short history lesson:
The development ended up dragging out to the point where the base kernel features needed for new devices not existing.. so you could use the stable kernel which didn't support much, or you could try the development kernel which tended to be wildly unstable or you could use the disto kernels (RedHat etc) which attempted to patch drivers from the unstable branch into the stable branch resulting in something almost as unstable as the development branch.
I still have nightmares of the day someone presented me with a brand new IBM server in which the Old kernel couldn't see the disks, the dev kernel crashed on boot, and the distro kernel would crash several minutes after starting. (I ended up going with a hand built custom kernel + patches).
It doesn't matter how many times you whine on slashdot or troll the kernel list. No one who remembers the old stable/unstable branches wants to go back to that nightmare.
Also FYI: There are several projects that QA the Linux kernel testing branches and report the results back to the kernel devs.
The problem being is that many managers *think* that some magical process can allow shitty programmers to do great work, and then lay off the great programmers to get cheap-o developers because Agile means quality, no matter how bad your workforce is.
Of course this isn't how most of the well-liked software is done, but it's done *all the damn time* in enterprise software land. Leading to a paradox of free and cheap 'consumer' software generally being a *ton* better than equivalent enterprise software packages which generally cost a whole lot more (when equivalents exist).
XML is like violence. If it doesn't solve the problem, use more.
Averages really don't work for that kind of project. My contribution to the Linux kernel: I found a bug and it was an easy fix, so I submitted a patch. I changed 8 lines of code in a driver. Haven't contributed before, and haven't since. If your name and email address shows up in the kernel change log, you may get an email from Greg asking in what capacity your contribution was made. The data is compiled into reports that give more details than the article. For example, about one third of the contributors, like me, only ever submit one patch. If you just average that with the regulars, you'll get a very skewed image of kernel developers.
You're right, "Greg Kroah-Hartmant" is not a Linux superstar, a person by that name doesn't exist. The correct spelling is "Greg Kroah-Hartman".
I think you confuse "the art of programming" with "the craft of programming." If it were the former, you'd be allowed to put the noses on sideways, like Picasso, and call it "art". But as a craft, you need to produce the best work possible, even though it certainly contains an element of art.
I work on safety-critical software. We are required to do rigorous unit testing on every line of code by The Authorities. And I regularly find bugs in my code in the process. In fact, since I will be developing unit tests anyway, I (try to) make it a practice to do develop a module and its test simultaneously, which is more efficient than doing the unit test at the end, as is the common instinct by those who regard unit tests as "useless."
I also think you confuse "useless" with "efficient." Depending on the use of the software, unit tests may be an inefficient use of development time - as the Linux folks evidently believe. So, I don't do unit tests for every category of software. For example, there's no need to do that for a simple utility script. But I wouldn't want to fly in an airplane whose autopilot code was never unit-tested, and whose developers instead simply assumed that all the code they write is bug-free.