eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As the linux world congregates this week in New York, the center of attention, as always, will be Linux creator Linus Torvalds. Resting up from the long 2.4 kernel development cycle, Torvalds took time out to exchange e-mail messages with eWeek Senior Editor Peter Galli about 2.4 and beyond.
eWeek: The 2.4 kernel has been enthusiastically embraced by users. What aspects in the kernel are you most proud of in that regard and why?
Torvalds: I like the fact that I feel we got the file system interfaces right … and Ive been very happy with how the new design turned out internally. These kinds of infrastructure issues arent visible to users (except, of course, as a result of how well it works), but it really makes it a lot easier to maintain when there is a strong and solid architecture to build on.
eWeek: But Linux still has a long way to go before it yields the performance of high-end Unix systems. Do you agree, and, if so, what do you plan to do to correct this going forward?
Torvalds: I dont worry about the performance issues. Linux already holds the world record SPECweb numbers. The thing that continues to be much more important than high-end Unix systems is really more of the user interface issues, ease of use for normal users. Thats the stuff that really matters in the end, once you have the good, solid foundations—which I think we do. And I think Linux is doing very well in this area, too; the whole graphics and UI scene has pretty much been revitalized in the last few years, and were doing really well.
eWeek: One of the criticisms of Linux at the enterprise level is that it is not yet capable of supporting workloads like [enterprise resource planning], [customer resource management] and business intelligence and cannot run multiple mixed workloads on [symmetric multiprocessing] servers. Do you agree, and are you addressing this going forward?
Torvalds: This is not about technology anymore. Its about the business support infrastructure still being built up. Its a continuing process, getting more and more applications and support. Its happening, but its a fairly conservative market.
eWeek: When will you start the process with 2.5 development?
Torvalds: Historically, its been about four months after the release of the stable kernel. Partly just because people take time off and relax a bit, but even more because there is this need to follow up on the stable release to see that you crossed all the ts and dotted all the is. So say May or so.
eWeek: What are your goals going forward to the 2.5 development tree?
Torvalds: I tend to avoid very specific plans. It all depends on what works out and what really ends up being most important. I want to revamp some of the device driver interfaces some more. We got many issues worked out in 2.4.x, but we have a few things still left that need to just be re-engineered. Things where you can trace back the design to the original kernel 10 years ago and where the situation has just changed so much that some of those design decisions need to be revisited. So Ill basically continue to make sure that the design and the underpinnings are well-done and stable. With a good platform to work from, you can do wonderful things.
eWeek: As the Intel [Corp.] 64-bit Itanium processors come to market later this year, questions are being asked about how you use one kernel base to give good performance all the way from one to 64 processors. Are you going to work on a branch of the Linux kernel specifically for multiple processors?
Torvalds: Well see. A lot of that kind of stuff is really about tuning, and it takes longer than people sometimes realize. Im still hoping that a branch especially for that kind of hardware is going to be unnecessary in the end, but, at least during development, youll see a lot of people going off in different directions, testing out the problem space. Some of them will work; some of them wont. And well have to wait until that point to know whether the generic kernel line will be able to support those kinds of boxes without penalizing the “normal” workload. And that, ultimately, is what is going to decide how well handle the big-iron boxes. I actually believe that well be able to handle them from a common source base.