Welcome!

Linux Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Linux

Linux: Article

Linus changed his source habits & why it doesn't matter

Developers have three options for advancing the Linux kernel.

(LinuxWorld) -- Linux is in greater demand every day. People want to run Linux on everything from wristwatches to mainframes. Thankfully, the core kernel developers aren't burdened with the responsibility of making Linux run on a wristwatch, but they do have to deal with desktop and server demands. People want the kernel to accommodate more processors, different hardware architectures, more types of I/O, more robust and complex network support and filtering, not to mention emerging hardware peripherals ranging from InfiniBand special-purpose high-speed network adapters to cheap digital cameras.

Talented programmers addressed these issues. They submited patches, which they felt were dropped into a black hole. They felt ignored, and, in some cases, they are right. Some ISVs feel as if the core kernel developers are an exclusive club that resents and rejects contributions from outside the inner circle, especially from organizations where capitalism is involved. I don't know if that's true (I doubt it), but the perception can be destructive.

Many people have offered various suggestions on how to improve the process of accepting and integrating kernel patches. I don't have space to tackle them all, and I doubt if my endorsement would make any difference. I do have a bit of advice for those who have more influence on the process. (If you're interested in reading up on all the ideas being tossed around, visit one of the many Linux kernel mailing list archives. You can find links for two of them at http://www.kernel.org/.)

Free advice for free software

Much of the discussion is politically motivated, and some of the antipathy is based on personality conflicts. Some of the suggestions are purely logistic in nature, for example, that kernel developers should use a more intelligent means of submitting and applying patches than the patch and diff utilities.

It appears Linus Torvalds is doing just that. Earlier this week he announced he started using BitKeeper, a distributed source management system. He wrote in his weekly kernel update, "...I've spent about a week trying to change my working habits and scripting bitkeeper enough to (a) import a good revision controlled tree into it from the 2.4.x and 2.5.x patch-archives and (b) try to actually accept patches directly into bitkeeper."

This is good news. BitKeeper isn't an instant panacea, however. "Quite frankly, so far it has definitely made me slower -- it took me basically a week to get about 50 patches applied, but most of that time by far was writing scripts and just getting used to the thing," Torvalds writes. "I expect to be a bit slower to react to patches for a while yet, until the scripts are better."

As great as BitKeeper might be and as wonderful as Torvalds has proven, we need to keep these two facts in mind:

  • Linus Torvalds is not God
  • The Linux kernel is open source, and it is licensed under the GPL

It is difficult for me to criticize the way Linus Torvalds folded patches into the Linux kernel in the past. Anyone who is tempted to do so should remember how much we Linux users owe to the talent and years of hard work of Torvalds.

Nevertheless, for the sake of argument, allow me to assume the worst. Suppose Linus deliberately ignores patches from some people, and in so doing occasionally works against the best interest of all Linux developers and users. Suppose Linus rejects some patches, not because the patches are without merit but because they come from IBM or HP employees, and he doesn't want those companies to have any influence on the kernel.

Or, how about this? What if BitKeeper is using the worst tool for collecting patches, evaluating them, and applying them? What if BitKeeper is perfectly fine but Torvalds uses it incorrectly? What if he never "gets used to the thing"?

I seriously doubt the situation is nearly as bad as these worst-case scenarios, but it is likely that there is an element of truth to at least some of these claims. Why? Because Linus Torvalds is not God. He has a finite ego, IQ, energy level, attention span, and suffers to some degree from all of the other human limitations you and I share. He is predisposed to handling things one way and not another. It is possible that his way was the best way when the kernel was smaller and more manageable, but it is no longer the best way. In other words, it may be true that regardless of the source management tools he uses, the Linux kernel has outgrown Linus Torvalds.

If so, there is still one more thing you can do. Remember that the Linux kernel is open source.

If you can set up a system that manages the progress of the Linux kernel better than Linus can, then go for it. Linus Torvalds may be able to stop you from calling your kernel "Linux," but he can't stop you from taking the kernel as it exists today and doing a better job advancing it. If you're worried that kernel developers simply won't cooperate with you out of a sense of loyalty to Linus, then keep reminding them that Linus Torvalds is not God. Eventually it will sink in.

Okay, now. Any takers?

If not, then I have one last bit of advice. Keep on making suggestions on how to improve the process. In the meantime, try to work with Linus the way he prefers to do things, whether you think he's right or not.

Postscript

In case you're wondering, here's how I feel about the current branches of development on the Linux kernel. I haven't been very happy with the Linus-managed 2.5 branch as of late. It usually doesn't even compile on my system. Dave Jones is aggressive about cleaning up the problems with the 2.5 branch and merging fixes and features from other branches. Jones' patches usually compile for me (although they make it difficult, but not impossible, for me to use the NVidia accelerated driver). You have to be pretty daring to mess with any of the 2.5 branches, whether they're from Linus or Dave. I run the unstable branch of Debian, so I tend to take risks in order to learn more about Linux, but I'm not comfortable running any of the 2.5 kernels yet except as a short experiment.

I miss the frequency with which Alan Cox improved and experimented with the 2.4 branch, so I was very happy to see Alan post some patches to the 2.4.18-pre tree. I'm currently running 2.4.18-pre7-ac2, which has been working great.

Whenever Linus reaches a reasonably stable point in his kernel branch, I usually find myself going back to one of his versions. Whether I do so in the future is uncertain, which is as it should be. It all depends on who does it best.

More Stories By Nicholas Petreley

Nicholas Petreley is a computer consultant and author in Asheville, NC.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.