Slashdot Mirror
Behind the Scenes in Kernel Development
An anonymous reader writes "Some interesting changes took place in the way the Linux kernel is developed and tested. In many ways, the methods used to develop the Linux kernel are much the same today as they were 3 years ago. However, several key changes have improved overall stability as well as quality. This article takes a look behind the scenes at the tools, tests, and techniques -- from revision control and regression testing to bugtracking and list keeping -- that helped make 2.6 a better kernel than any that have come before it." We might as well mention here (again) that a couple of new kernels are out: leif.singer writes "2.6.3 and 2.4.25 are out, fixing another vulnerability in do_mremap()."
"Much time is spent teaching people how to write code but never really reading it. This is a perfect example of how to do it and why you would."
Reading code can be a huge help in becomeing a better coder. You see how other coders do things. Learning from their bad on what not to do and seeing new good methods you may not have come up with on your own.
Evolution or ID?
Linus never claimed everything was working 100%. In fact, if you followed the list, quite the opposite. That is not what 2.6.0 meant at all. He's not lying, your just reading into what 2.6.0 way way too much. And he did do the '2.6 but not quite' thing a good bit with the 2.6rc's.
.0 relase.
Name me one piece of software that worked as expected with a
That's exactly what Linus does: there is such a series of release candidates (first introduced prior to 2.4). You can argue that it isn't long enough, but there's an obvious counterargument that if you wait forever nothing will ever get released.
I can't think of a x.y.0 release of any software project that's been properly stable. It's not just linux, it's the way the world is. You could argue that software never ever becomes perfectly stable: marking a series as "stable" is really just shorthand for good enough that further development is largely maintenance, therefore we expect the structure and codebase to remain stable", not some guarantee that they'll never go wrong. It's more a development term than a performance or reliability term, though the stability of development generally arises from the performance and reliability being sufficient to obviate the need for large changes to the code.
Even quite late in stable kernel release cycles there's occasionally a shocker - anyone remember 2.0.33?
If you don't like those kernels, just stick with 2.4 until a distribution ships with 2.6.8 or so. For what it's worth 2.6.(1+) has been fine for me.
Nobody's lying to you - there has to be some cut-off where a kernel series is declared stable, and by and large I think Linus judges it pretty well.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
It's still amazing to me that a project as large as Linux was able to be so successfull BEFORE the changes that were made to the development process. It lacked a centralized CVS, coherent bug tracking, automated testing... These are all things I use in the smallest of professional projets. Many eyes goes a long way towards compensating for having many hands in a big project, but some structure seems like it's helped.
It's really quite annoying, because those who follow Linux know the first "stable" kernels aren't stable at all, therefore avoid it, therefore defeat the point of testing it for Linus, but beginners think "cool, a new stable kernel", try it and are disappointed, giving a bad name to an otherwise great kernel.
The problem here is not with the kernel numbering, it's with your understanding of the kernel numbering. An even-numbered kernel is "stable" in the sense that the developers promise they will not muck with the kernel in deep ways, such as changing APIs or replacing VMs (er... well, usually). It is *not* necessarily stable in the sense that it works without problems.
This is why you never see Linux distros jumping on early stable versions as their default kernel, they know that you have to wait a while and let the early bugs be shaken out.
As to whether or not the use of the word "stable" is intended to fool newbs who don't understand this into doing testing -- I don't think that's the case.
But, hey, if it works... ;-)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I don't like to start new threads but I didn't see this: A general "Thank you for your time, effort, and a job well done" to all of the kernel hackers out there. They're fixing kernel level bugs that are almost at the hardware level while M$ is still patching their web browser. I don't think there's any doubt which system is ultimately more secure.
Can anyone take a guess how many low-level memory exploits are in Windows XP, 2k, or others? Perhaps it's irrelevant. Who needs to crack the low mem when there are so many ways into the system at the document level?
+++ATHZ 99:5:80
Is that true that Linux is developed using the proprietary BitKeeper? Why not Subversion or CVS or RCS? I just tried to download BitKeeper and there's a strange question in the download form: "Do you anticipate implementing a source management system in the next: [Please Select]" What's the deal? Don't just tell me that if I want to contribute to Linux, than I cannot contribute to Subversion... If that is indeed the case, then what are they nuts? No wonder that Subversion is maturing so slowly, when all of the Linux contributors are legally obligated to not help it. But is that really fair? I'm sure Linus Torvalds would never choose software with such an EULA, so who has made that decision? Was BitKeeper always proprietary and anticompetitive?
For what it's worth, 2.6.0 and the subsequent minor revisions have worked flawlessly for me and many associates. You seem quick to assume that they named it a "stable release" prematurely. Have you considered the altertnate hypothesis that you are in the minority of users who have encountered problems? If so, that's not a dishonorable place to be...somebody has to be the poor soul who encounters a bugs. (Thank you, by the way, I appreciate your hardship.)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
This is exactly why Universities should have the senior or junior CS design-project be to add some significant functionality to an existing large project. There simply isn't enough time to build something that large from scratch in that short amount of time, and the things you learn from working with a large codebase are invaluable. Furthermore, in the real world you will spend much more time improving other people's code then you will writing from scratch anyway.
An addendum: your experiments don't have to be anything spectacular. Here are a few:
- Try adding a few printk statements throughout the code, decide when you expect they will print and what they will say, and confirm it.
- Try tuning a sysctl or hardcoded value. See how it affects performance. Do microbenchmarks or benchmark real systems. Make pretty graphs. (Graphs are fun!)
- Add a likely() or unlikely() option to help the compiler's branch prediction. Again, test the performance. Or take one away - it's possible someone was wrong about the performance
And in user-level code, there are even more things you can do:Another project I've considered is adding likely() and unlikely() equivalents to boost. A lot of people use this code, so increasing its performance a little would be pretty beneficial.