Welcome Guest. | Log In| Register | Membership Benefits
January 29, 2001 (12:00 AM EST)

Torvalds: The Guardian Speaks

Torvalds: The Guardian Speaks

By

Linus Torvalds, the inventor, lead developer, and so-called guardian of the Linux kernel, sheds light on the release of Linux 2.4, the operating system's future, and his role as guru-in-charge of Linux.

Question Linux 2.4 is now out the door. There are thousands -- if not millions -- of open-source developers contributing to the Linux kernel, but ultimately, you alone must sign off on it, correct?

Answer Yes. In the end, it's not that horribly hard. The worst part is just the herding of developers and trying to cajole them into doing the right thing -- or at least make sure they don't get too upset with me when I say no to something. Another horrible thing is having the press trying to second-guess me on when the release will happen.

Question As a man with a full-time job at Transmeta, is it becoming too much for you, in terms of energy and what you can devote to development of the Linux kernel?

Answer I'm lucky, or maybe I have just made the right decisions in life. Transmeta has been very supportive. When I said I needed to concentrate on getting [Linux version] 2.4.x out, the people here basically asked me what Transmeta could do to make it easier. And it does help that I've been doing this for 10 years. Making a release is fairly stressful, but at the same time, it's something I've done before. And I have a fairly good feel for it, which makes it much less stressful.

Question But the Linux 2.4 kernel was more than a year late. Wasn't it scheduled to be released by year-end 1999?

Answer The original plan was to try to aim for a nine-month productization cycle, and part of the reason for that was that I expected the changes for 2.4.x to be much smaller than they ended up being. My original main goal was to clean up the SMP scalability to four CPUs, and it kind of grew into a major file-system redesign. That said, everybody knew the nine-month goal was unrealistic. But it was kind of "if we don't have anything to shoot for, we certainly won't hit it." I was hoping we could get it down to a year or so.

The gap between [Linux version] 2.0 and 2.2 was well over two years and had been quite painful. [The update to 2.4] ended up being almost two years, and while it never became as painful as the 2.0 to 2.2 gap -- probably because 2.2 was maintained more actively -- it's certainly still true that two years is a bit too long.

The good news is that for the 2.5.x series, we don't have anything like the 2.3.x wish list. Of course, that may change. I'm really happy with how 2.4.x ended up, though there's the obvious few months of watching stability, etc. Maybe the 2.5.x series will be less intrusive, which would translate into a simpler release next time around. Knock wood.

Question If there was a Linux board, such as the Linux Lab, with 20 engineers devoted full-time to finishing the code, finalizing it, and releasing it as soon as possible, do you think the same delay would have occurred?

Answer Probably. Delays are kind of inevitable in this business. Of course, because I never really had any hard deadline that I set for myself, my only criterion was really "when I'm happy with it." I probably didn't get as hung up about the release as an "official" body would have, and maybe a Linux Board would have held people to stricter deadlines. Who knows? At the same time, I think 2.4.x happened when it was ready, not before, and not later.

What didn't get very much press coverage was the fact that we really did have a Linux Lab working on testing. In fact, there was more than one. All the major vendors had a 2.4.0 stress-burn setup, and we found quite a few bugs that way. I'm really happy with the level of support that I got from Linux vendors in this area.

Question Windows 2000 was years late. But that was Microsoft's woe, and its channel was upset, too. In this case, your partners -- Red Hat and other Linux distributors -- had their products ready to go in the fourth quarter of 2000. Weren't they upset when Linux 2.4's release was delayed?

Answer So far, the vendor comments I've gotten have been pretty philosophical. Many of them expected it to be even later, actually, and I never got a complaint. Most of them seem to have covered the kernel development fairly well, and I think they'd have been as unhappy as I would have been if I had released 2.4.0 too early.

Question How much pressure did you get from Linux companies, whose profits were hanging in the balance until 2.4 shipped?

Answer None at all, really. To some degree, I got "what do you think the timing will be?" kinds of questions, but absolutely no pressure. Nobody said "we'd really like it for the Christmas season" or anything like that.

Question But how about the kind of pressure that IBM, Intel, and Oracle can exert when they're hungry to ship product? Are you feeling more internal pressure, given the vast constituencies in waiting?

Answer Forget about the Oracles of the world. Their product time lines are long, and they want to test things on the shipping version. So they really don't have any reason to even ask me. Only now that 2.4.0 is out will they even start to think about it becoming an issue. Intel obviously has the IA-64 issue, but at the stage they are in, they were happy with even a non-released 2.3.x test kernel. Having a real stable IA-64 2.4.x kernel out probably won't be an issue for them until later this year.

Question You alluded to a time in the future when you won't be the one in charge of Linux. Who or what will be? Is there a new company, entity or organization being prepped to take the reins from you as guardian of the kernel?

Answer What will be, will be. You ask the wrong questions.

Question If a large, full-time team of engineers directed by a full-time leader worked on the Linux kernel for the past year, might some of the features planned for 3.0 made it into the 2.4 kernel?

Answer Ah, the old question about discipline as the best way to reach your goals. Is an army known for its thoughtful approach? Would Mozart have been more productive if he had scribes to help him, a secretary and a CEO to lead his way? What if? We'll never know.

However, we do know that the sometimes disorganized approach -- the strange and motley band that defied traditional ways of writing software, the crowd of individuals rather than the sternly disciplinarian army of ants -- has so far done a lot better than anybody expected.

So far, we have a track record of having done a lot better than a lot of "disciplined" companies with full-time leaders.

Question Do you envision a day when you won't be the one signing off on the final Linux kernel code?

Answer Some day, sure. Not in the near future, though. I don't plan that far ahead.

Question Might you hand over the reins to the Linux Lab in the next two years and serve as an adviser rather than lead developer? Might you sell the Linus Torvalds trademark to a company, entity or other person? Might you license it?

Answer Ah, you have discerned my plan! I will have to kill you before you disseminate it to the rest of the world.

»More from CRN


CAREER CENTER
Ready to take that job and shove it?
SEARCH
Function:

Keyword(s):

State:
SPONSOR
RECENT JOB POSTINGS
CAREER NEWS
Go beyond Google and get vertical. These specialized search sites will help you find the business information you need -- fast.

Ari Balogh was named to the post of chief technology officer as the companys for a "realignment" of employees.

Advertisement


Specialty Resources

Featured Microsite


Microsites

Featured Topic

Additional Topics

Crush The Competition

TechWeb's FREE e-mail newsletters deliver the news you need to come out on top.

Techencyclopedia

Get definitions for more than 20,000 IT terms.

Techwebcasts

Editorial and vendor perspectives


Vendor Resources


Focal Points