James Buchanan22 August 2007, 2:20 PM
Page 2 of the interview with Linus Torvalds.
APC: When do you expect to see a kernel version 3.0? What will be the major changes or differences from the 2.6 series?
LT: We really don't expect to need to go to a 3.0.x version at all: we've been very good at introducing even pretty big new features without impacting the code-base in a disruptive manner, and without breaking any old functionality.
That, together with the aforementioned lack of a marketing department that says "You have to increase the version number to show how good you are!" just means that we tend to just improve everything we can, but you're not likely to see a big "Get the new-and-improved version 3!" campaign.
APC: There doesn't seem to be a Linus kernel anymore and an experimental (e.g. Alan Cox kernel, etc) anymore. Is this true? If so, is it because you have the 2.6 series pretty much exactly where you want it?
LT: Well, part of it may be that we've gotten better at handling the code flow issues, and so maybe there's less reason for various experimental kernels. That said, there's still the -mm tree (Andrew Morton's kernel) where a lot of new code goes first. It's maybe less about "experimental" than about "a first testing ground before merging into Linus' tree", but that's not so different from what -ac (Alan Cox's tree) was about.
And there are still a lot of specialized trees for specific things. In fact, it's one of the things I wanted git to make easier to do, and if you want to follow network driver development before it gets merged into my tree, there are trees for that, and for sound drivers etc etc.
But I do think that part of it is that over the years we've found what works, and that the current development model is reasonably good.
That said, I'm sure we'll eventually hit some issue that gets peoples blood boiling, and we'll have a tree for some changes that I don't think are appropriate and am not willing to merge, and that's as it should be: unlike a lot of other open source projects, I've always encouraged people to try their hand at forking off a kernel project of their own to scratch their own itch.
So I don't think such project forks are bad at all, it's how a lot of development is done. Obviously, most development is about "micro-forks" and people don't even think of them as real forks at all, but I actually think it's good to encourage experimentation - and by keeping it friendly, if some experimental kernel shows that it was actually the right direction, we don't end up having psychological road-blocks to switching over or to merging the code...
May the best code win.
APC: Do you think Linux has had an impact on computing in the past decade? If so, what stands out the most?
LT: I think Linux has affected the OS landscape a lot, but even more than that, I think Linux was instrumental in making the whole issue of Open Source move into the mainstream software development consciousness.
There had certainly been Open Source projects before Linux, but Linux was big and successful, and actually changed how people viewed them. Part of that was that Linux took a lot more pragmatic approach to what used to be called "Free Software" (and is still called that by some), and moved it from being a fringe and sometimes pretty extreme ideology to be something that was just "technically better".
And I'll certainly take some of the credit for that personally. I dislike the frothing-at-the-mouth ideology (to me, ideology should be something personal, not something you push on other people) and I think it's much more interesting to see how Open Source actually generates a better process for doing complex technology, than push the "freedom" angle and push an ideology.
And I think that pragmatic approach was what made Linux and Open Source also much more palatable to many more people, and helped make it mainstream.
APC: For those eager to make their first contribution to the kernel and have it accepted, what would your recommendations be? (Any areas that need help more than others, any good books for kernel hackers; however you'd like to interpret this question).
LT: It's hard to give advice, because it's different for different people. The big thing is to not think too big - you don't start out by rewriting some subsystem. Start out with some small annoyance, and see if you can fix it. And do something you're really interested in - kernel programming is easily complex enough that if you're not really interested, you'll lose your motivation before you really get anywhere.
Note from James: I recommend you first read "Linux Kernel Development" 2nd Edition by Robert Love, published by Novell Press, ISBN 0672327201. Written by a professional Linux developer and "insider," it focuses on the 2.6 series kernels. This book gives you the essential "big picture" before plunging you into mind-boggling details.
APC: Out of curiosity, do you have anything to say to hardware manufacturers who refuse to release datasheets or specifications about the functioning of their hardware so it could operate with the Linux kernel?
LT: Is "I hope you all die a painful death" too strong?
The good news is that a lot of hw manufacturers are actually doing the right thing. Intel in particular has improved wrt open source a lot, and for that reason I tend to suggest that when buying a machine, just make sure that you buy one with Intel graphics and wireless. That takes care of the two biggest annoyances right there.
But Intel certainly isn't the only one, and we're doing fairly well in general - with just a few dark spots.
APC: You've made an enormous contribution to community service and to the lives of countless people with Linux. People in third-world countries are donating old or second hand machines, and Linux distributions are free of charge and come with sometimes tens of thousands of free programs. Is there anything else about Linux you are really proud of?
LT: Actually, I'm not all that proud of the "community service" and "third-world countries are using Linux". Simply because it wasn't really what I was aiming for. So that feels like a great bonus, but it's not something I see myself patting myself on the back for. The credit for that goes to a lot of other people.
So the thing I tend to be personally proud over is just the fact that I've had the tenacity to "just do it" for over fifteen years, and that Linux has fostered a culture of good open source technology. I'm proud of a lot of the technology too, of course.
APC: You said you were proud of the technology. What do you mean by this - something like better memory management algorithms than those in commercial UnixTM kernels, better flow of control in a complex process like a kernel?
LT: I think we have tons of areas where we're just better than anybody else. We handle portability better, we handle the development process better, and yes, we also end up having better memory management and a better filesystem layer than anybody else.
So there's tons of things on the technical side that I'm really proud of how we handle. And hey, I'm obviously biased, and some people will disagree on any particular feature, but that's what makes things interesting.