Linux Weekly News, Linus Torvalds keynote

Linux Weekly News
Contact us

LinuxWorld coverage - Linus Torvalds keynote

August 10, San Jose
Linus was introduced by Larry Augustin, head of VA Linux Systems. It was a brief introduction; Larry started by asking how many people in the audience had contributed something that appeared on a Linux distribution CD somewhere. A fair number of people raised their hands.
How many had contributed something that appeared on a Windows CD? One or two people raised their hands.
That, said Augustin, is the strength of Linux - the contributions from all of those people It is that contribution that makes Linux different. All very true.
Linus took the stage; a flood of people ran down the aisle to take pictures. It looked rather much like groupies rushing the stage at a rock concert. People cheered and threatened to head into a standing ovation; Linus, looking a little embarrassed, asked the audience to stay calm.
Linus didn't, he said, want to do a normal, boring talk. But the LinuxWorld organizers were absolutely adamant that he show up. So, his plan was to do a technical update; the technical stuff, after all, is the part that he finds exciting. Following that would be a question and answer session.
There was a brief "warm, fuzzy gratitude section" to Linux users as a whole for being such a great community. Then it was time for the technical stuff.
The current stable kernel is 2.2.11, just released. With this release, the handoff to Alan Cox and company is complete, which is a major milestone. About all Linus did was to "sprinkle holy penguin pee" on it. Linus thinks this is great, now he can ignore the stable kernel and go do the fun work.
2.2.11 has a few security updates, including a fix for a "rather silly" firewalling bug and some securelevel and capability fixes. There are new drivers for disk arrays and Mylex and Compaq controllers, and a number of updates to older drivers. Of importance to a number of users will be that the ISDN code has finally been resynchronized. Linus hopes that 2.2.11 will last through to 2.4.
With regard to 2.4, a tentative feature freeze is a few weeks away, meaning that Linus knows which features will be present, more or less. A real code freeze should happen in a month or two, with the real 2.4 release happening toward the end (close to the very end, apparently) of the year.
Linus is really trying to change the timing with 2.4. The 2.2 kernel was 2&1/2 years in coming, far too long. Thus, 2.4 did not try to bite off too much. To a great extent, it is a refinement of 2.2. It makes better use of many of the new interfaces which appeared in 2.2, but had not actually been used much. The infrastructure for symmetric multiprocessing, for example, has now really been put into service. 2.4 will be have much better support for the Universal Serial Bus (USB) - not too hard, since 2.2 had none, for all practical purposes. There is I2O support, and a lot of improvements to resource allocation, needed for PNP, PCMCIA, and hotplug PCI stuff.
Early this year Linus had assumed that the next kernel would be 3.0. Instead, a lot of 3.0 features didn't make it in. For example, journaling filesystems. There are two projects active [Stephen Tweedie's work and SGI's XFS --ed], but neither will make it into 2.4. The Merced port will not be there, not too surprising since 2.4 is supposed to come out before Merced does. Clustering also got dropped.
Finally, says Linus, they really had wanted to include a "mauve screen of death" feature, but they ran into problems with patents held by Microsoft, so they had to drop that one too.
Then it was time to move onto the question and answer session.
Q: What are the plans for support of handheld devices, and also for Firewire?.
A: Much work is being done in support of handheld devices, much by the companies that are getting into Linux in the embedded arena. Linus has done some of it personally, "trying to get his Vaio to stay alive for longer." That means he is working on power management issues. Linus also wants to see the PCMCIA code more tightly integrated into the kernel.
As to Firewire, it is not very well documented or used, and could present unpleasant licensing issues. He hasn't seen very many firewire devices out there.
Q: Code quality is clearly very important to you, but there is a lot to keep track of. Where do you draw the line in what you monitor personally?
A: He starts by having an awful lot of testers (the users). Linus really cares about the core system, process management, interrupts, memory management. With things like filesystems, he often can't even test them, and they are not his area of expertise of interest. For filesystems and drivers, he really has to trust the expertise of the maintainers.
Q : What about coding style?
A: He is not all that worried about style issues. Code he deals with directly has a fairly straightforward style, but areas maintained by others should use the style they prefer - as long as he doesn't have to look at it too deeply. If he does find himself working a lot in a given area, he ends up telling to maintainer to "indent the code the way God meant it to be."
Q: What is the future of USB and APM support?
A: USB has been put forward as one great thing, but that really is not true. USB gives you an electrical standard, but says very little about the protocol used, and that is where the troubles can come in. 2.4 will have a number of basic drivers for mice, keyboards, cameras, scanners, etc. More esoteric devices will probably not be supported. Usually adding support for individual devices will be relatively easy, now that the infrastructure is in place.
Regarding APM, what really wants to do is to support ACPI instead, which is a more direct approach. APM is meant to work on larger time scales, where things happen on the order of seconds. With ACPI, you can power things down "between clock ticks," giving much finer control. He currently has code which works on exactly one laptop in the world, which is a start.
Q: Will devfs be in 2.4?
A: Probably. But devfs has been "probably" for a long time. He doesn't like the naming scheme used by devfs, it looks like a flashback loved by old-style Unix hackers that leaves all others clueless.
Q: When will the kernel be scalable beyond 4 processors?
A: Linux is currently scalable from four to eight processors; the 2.3 and 2.4 kernels will be much better in that area. Linus expressed confidence that the "friends in Redmond" will try hard to find problems, and will thus serve as the beta test site. But they will have to work much harder at it this time around. Beyond that is unclear; his approach is to support whatever is realistic today.
Q: When will capabilities actually be used?
A: Capabilities have been present in the kernel for a while, but are still kind of simplistic. The problem is that it is hard to find a good interface for controlling capabilities [LWN has covered the capabilities discussion extensively in the kernel section]. With 2.2.11 they added the support for the init process to set a system-wide cap on capabilities, thus providing a sort of "securelevel" protection. Security-conscious sites can rule out many operations once the boot process is complete.
The rest of the capability interface will have to be thought out more, a process which will be aided now that the infrastructure is in place.
Q: What about NUMA support?
A: That is an issue for 3.0, driven mostly by vendors with an interest in that area. The kernel has no NUMA support now, and adding it will be a big project. He expects some rudimentary support in 3.0.
Q: Will the Merced port be a pure 64-bit system?
A: Yes, but it will still be able to run 32-bit binaries, just like the UltraSparc port can now.
Q: When will there be DVD support?
A: (Winces) There are many problems with DVD support, and technology is not one of them. There are a lot of trade secrets around how DVD information is decrypted. There is interest in working this out, but there seem to be only two options. Either you need a hardware unit which does DVD decoding, or it will be necessary to buy a commercial DVD player.
Q: When will the real-time Linux patches get folded in?
A: They have recently rolled in an interrupt cleanup patch, which makes the real-time Linux patch "shrink to basically nothing." Linux still does not do hard real time, and probably will not anytime soon. People who really need real time can keep patches up to date much more easily, but Linus does not want to encourage the use of hard real time except in the rare cases where it is really necessary.
Q: There have been concerns about the staleness of the ISDN code. When will that be improved?
A: Linus is now happy about the ISDN code, the issues there have been resolved. He will syncronize with the current ISDN code. The ISDN maintainers are now aware that they need to help to keep things in sync. 2.2.11 has the current code, and 2.4 will as well. Updating ISDN at this point is not a feature freeze issue, just an update of already existing features.
Q: What about asynchronous I/O support?
A: Linux currently handles async I/O with threads. 2.3 remove a limit on the number of threads possible, thus helping with this issue. There are those who say that the NT approach is really the right way, and he will be thinking about it "over the years," but no such thing will go into 2.4. Asynchronous I/O can be done much more cleanly with threads.
Q: How far away is software RAID and LVM from being stable?
A: Ask the people who are using it. Software RAID is already stable for a lot of people. It is currently broken in 2.3 because the code has not yet been updated, but it will work in 2.4. The LVM patches will not be in 2.4 unless he hears from a lot of people that they are working well.
Q: What are the plans for support of hot-swap technologies, such as CompactPCI?
A: Hot-swap support came out cleanly due to the thinking that went in regarding ISA PNP and PCMCIA. They all have the same needs, which have to do with careful resource allocation. The infrastructure is done. There will be no hot-swap PCI support in 2.4, but the structure will be there so that people can work on it.
Q: What about support for kernel debuggers?
A: As a lot of people know, he hates kernel debuggers. He thinks they make things too easy, that the result in people fixing the symptoms and missing the underlying reasons for problems. But there are a couple of small patches that seem truly useful and those will go into 2.4.
Q: 2.2 has horrible out-of-memory behavior, and tends to kill the wrong processes. Will that be fixed?
A: The problem has been mostly fixed in 2.2.11. You can still get into "bizarre cases," but most of the problems are fixed. Many of them came down to an off-by-one error that made the kernel not realize that it was running out of memory.
Q: More nontechnical people are getting involved with Linux. Are they members of the Linux community, and how can they help?
A: Linus likes kernel development, but he does not see non-kernel developers as lowlifes. He has been saying for years that most of the exciting work is outside of the kernel, and is perhaps not even programming. He put out Linux so that people could find uses for the system and problems that he does not have, so that it could be improved. Users can help by trying things out; if it doesn't work, they can try to fix the problems or at least bring up the issue.
Q: Will there be ALSA support in 2.4?
A: He hopes so. One issue has been the ISA PNP stuff, sound cards are one of the areas where it is truly a big deal. Sound is high on the list, but might not make 2.4.0; it could be folded into a later 2.4 release.
Q: How do you feel about internet services, such at HTTP or SMB, being implemented in kernel space?
A: In-kernel servers are OK if they are well done. The kernel HTTP server is very clean, he likes the code. People should be given gthe choice, and the kernel HTTP will be in 2.4. It may be something you enable only to win performance benchmarks, or as a teaching aid.
Regarding SMB, he does not think that the Samba people would want to do it in the kernel. The problem is just far too complex to be solved in kernel space.
Q: Do you fear a class between commercial interests and open source?
A: Thus far he hasn't seen a single clash. Companies have their own agendas, and are happy to support development people to get what they need. Developers have been entirely happy to take piles of money. Schedules and product deadlines ("the mother's day release") have not been a problem.
Once the question period ended, Linus commented that he had been asked to read an introduction for the IDG guy (whose name I forgot) who would present the "community award" to the Free Software Foundation. It was a long-winded, excessive introduction, and Linus clearly hated having to plow through it. He read it directly off the paper, and managed to make it into a subject of some ridicule. He finished with "they won't make me do that again."
It got worse; the IDG guy came on the stage and went into a long-winded speech about what a great guy Linus was. It was clearly written by the same person who wrote the intro. Linus did well at keeping a straight face through the whole thing, but is was a painful thing to sit through. There was no sincerity to it.
Richard Stallman came up to the stage to claim the award, in front of the smiling lady holding the six-foot check. It looked like a scene from a game show. Stallman asked for a microphone; the IDG guy, clearly ignorant of what he was getting into, asked: "would you like to say a few words?"
There may have been a day when RMS didn't want to say a few words, but this certainly wasn't it. His answer was an emphatic "yes!"
RMS's speech was the usual GNU/Linux thing, and was actually quite restrained. He said that giving the "Linus Torvalds award" to the Free Software Foundation was sort of like giving the "Han Solo award" to the rebel fleet. People were listening to him, but many of them were at the same time watching Linus's children who were wandering around on the stage, having a great time. RMS said his piece before anybody got too uncomfortable, then wandered off with his check. The session ended with "Hard Day's Night" blasting from the speakers.