A: We've had screening processes in place for the longest time, but they've not been for IP issues as much as a way to let people comment publicly on new features, etc. Does putting the responsibility to find patent infringement on the patent-holders run the risk that the patent will come to light after someone has included patented material in Linux, after which it will be extremely difficult to extricate?
Finding patent infringement has always been a responsibility of the patent-holders. I didn't put it there... It is a fact that I do not encourage engineers to look up patent information, for example. You ask any lawyer about it, and they will tell you that I'm right. It's not the job of an engineer to try to find out about other people's patents, since that just taints them, exactly something you do not want to happen. Do you think the SCO accusations will result in any changes to the process by which code is accepted into the Linux kernel?
Not that I can tell. None of the SCO accusations have anything to do with IP rights; they're all about contracts between IBM and SCO. All the IP rights blathering by SCO was just that -- blathering -- the kind of "holier than thou" stuff where they tried to look like they had some moral high ground. The fact is that the stuff they have actually mentioned (RCU, etc.), was all IBM's intellectual property. Looking to the future, should hardware and software companies think about offering total indemnification to customers who might get sued for using open-source code later found to contain proprietary intellectual property?
Hey, if customers pay for it, why not? It's just an extension of a support contract. By the way, I'm getting really tired of the "proprietary IP" thing. How many times do I have to repeat that the SCO case isn't about IP at all, and that SCO has just been spouting crap when they have brought up their FUD (fear, uncertainty and doubt) about IP issues. Now that Linux is important at IBM, Oracle, Dell, HP, SAP and others, do you get more pressure to meet shipment schedules or add specific features?
I haven't personally felt any such pressure. Which is not to say that it may not exist, but might be more of a "Linus isn't very good at picking up strong hints" kind of thing too. ;) What fraction of your time in the Transmeta years did you spend on Linux, and what fraction do you think you'll spend on it at OSDL?
At Transmeta, it depended on what was happening, but for the last few months it was almost exclusively Linux (except when the new Transmeta chips came back, which is always exciting). Are you going to telecommute from Santa Clara, California, or move north to Beaverton, Oregon, where OSDL is headquartered?
Telecommute. I'll be visiting physically every once in a while. Will you change what you focus on at OSDL? For example, will you be taking advantage of their big multiprocessor servers? I'm presuming you'll be just as self-directed as ever.
Yeah, "self-directed" is a good word. It doesn't have any of the negative connotations associated with "stubborn" or "doesn't take commands very well". That doesn't mean that I won't take advantage of their big boxes, but I've always enjoyed the small (but powerful) variety more. Are you happy that Linux is used commercially primarily on servers? Would you rather see it be more of a mainstream desktop phenomenon? Obviously the two aren't mutually exclusive, but I'm curious which future you'd rather see.
Oh, I'd obviously like to see Linux more on the desktop too, but I take the long view, and I don't think it has to happen tomorrow. The reason Linux is strong on servers is that it is a much easier market to get into, and I'm very happy with where Linux is today in that area. And I absolutely do not see the server and desktop as mutually exclusive. In fact I personally think that a large measure of the technical "goodness" of an OS is how well it responds to different kinds of users, and I think specialised niche OSes are an evolutionary dead end. A while back, you said one of your main jobs isn't so much writing Linux code but rejecting submissions that aren't up to snuff. Is that still the case, and is that what you really enjoy?
It's still true that most of my time isn't coding per se. Most of my time is spent merging code, and talking to people about issues. The "rejection" part may not be most of it, but to some degree it's the most important part -- i.e. I see myself as not just a common repository, but also as an arbiter of "good taste". I'm by no means the only arbiter of good taste; every subsystem maintainer is one too, of course. But for the occasional (very rare, I'm happy to say) spats, I often end up being the final arbiter. Are there other open-source software development communities you particularly admire?
If I'd have to pick two, I'd pick KDE and the GCC group. I often end up clashing with the compiler people, because the kernel ends up having rather strict needs, and I hate how much slower GCC has become over the years. But there's no question that they're doing some good stuff. And I just like the KDE group, and have found it very responsive when I had issues. I was talking to (Red Hat chief technology officer and GCC backer) Michael Tiemann about his view that general-purpose compilers, well written, will incorporate broad optimisations that ultimately will produce superior code to compilers with chip-specific optimisations. But now I'm hearing that Intel's C compiler produces much faster software than GCC. Have you tried the Intel compilers, now that you can compile Linux with them?
I haven't really ever gotten around to using the Intel compilers, but I like the fact that there is competition and a baseline to compare against. And I personally disagree with Michael about general-purpose compilers. Yes, there should be a lot of shared code, but when it comes down to it, the thing that matters most for modern CPUs is just generating good tight code, and the generic optimisations aren't that interesting. But hey, that's just my personal opinion. I'm not really a huge compiler person; I just don't like how the high-level optimisations in current GCC versions are slowing things down without actually giving much of a boost to generated code for C. Do you ever wish you'd opted for a BSD-style licence instead of the General Public License (GPL)? (Unlike the GPL, BSD-style licences such as those used for the Apache Software Foundation Web server and the FreeBSD Unix offshoot permit open-source code to be made proprietary.)
Absolutely not. I personally think that the BSD licence is a dead end for serious projects, since it inevitably results in forking with no way to re-join if it becomes commercially viable. Forking a project is in my opinion hugely important, since forks are how all real development gets done, and the ability to fork keeps everybody honest (i.e. if you don't do a good job and keep your users happy, they can always fork the project and go on their own). But equally important is the ability to join back forks, when/if some group finds the right solution to a problem. And that's where the GPL comes in: you can really think of the whole licence as nothing more than a requirement to be able to re-join a forked project from either side. What fraction of Linux contributors these days are paid to do so?
Almost everybody of the major developers involved is paid to develop Linux in one form or another. Few of them started out that way, but once they proved their prowess, they had little trouble finding companies to pay them for doing Linux work. Who are your top deputies?
They change over time, and they tend to be subsystem-specific. For example, over the last year or so, it's been Andrew Morton (virtual memory, filesystem interactions, "generic" code), David Miller (networking), Greg Kroah-Hartman (USB, PCI hot-plugging), Jeff Garzik (network device drivers), Jens Axboe (block device layer), Dave Jones (AGP and clean-ups), Kai Germaschewski (build infrastructure and ISDN), Pat Mochel (device manager infrastructure and sysfs), Russell King (PCMCIA and ARM), Rusty Russell (cleanups and module handling) and Al Viro (filesystems). And that's ignoring the architecture maintainers who handle their own architectures (Itanium, PowerPC and AMD64) and other people that I probably just forgot. It's also ignoring people who have very specific subsystems, like Roland McGrath and Ingo Molnar who have worked on the signal handling and threading code, for example. But it really does change over time. And some people fade in and out over long periods -- they'll be very active for a few months, then they go away for some time, then they come back. Do you think Linux suffers from the issue that it's more fun to experiment with new ideas and new modules than it is to perform comparatively mundane work such as updating a driver for some out-of-date tape backup system or auditing older code for security vulnerabilities? Do you think Linux suffers more or less from this than traditional proprietary development processes?
I don't think Linux "suffers" from it. In fact, I think it's the real driving force for most new features. The mundane work has to be done as well, of course, but people do do it. Sometimes it happens just because they are paid to do it, but quite honestly, more often (I think) because the people involved are just proud of what they do, and dotting the i's and crossing the t's is part of making a good product. Some drivers, etc. do get left behind, but usually it's because literally nobody cares about them any more. They're either so out-dated that they aren't used any more (quite common for some old ISA crud -- I don't think people even remember how many strange CD-ROM controller cards there were), or because the people who haven't updated their hardware also don't tend to update their kernels. The latter happens in the embedded space, for example: once it works, you literally don't touch it any more. What's the most exciting feature of 2.5? (The 2.5 kernel, which Torvalds oversees, is the development version that will be replaced by the 2.6 "production" version for real-world use.)
Excitement is in the eye of the beholder. I doubt most people find my "exciting feature" very interesting. To me, the most important part of 2.5.x development has been the new block IO (input-output) layer infrastructure, and the POSIX threading stuff (the latter got back-ported to 2.4.x too). Both are to some degree just internal cleanups, and just make it easier to do things right, rather than huge user-visible features in their own right. But there's a lot of other stuff. The VM (virtual memory) is a lot nicer, and we scale a whole lot better. Better interactive behaviour (this is largely from the VM work, but the scheduler, etc. have been worked on). Any thoughts about what big changes will come with 2.7?
Ask me after the kernel summit. That's going to be one of the big discussion points.
For all your GNU/Linux and open-source news, from the latest kernel releases to the newest distributions, see ZDNet UK's Linux News Section.
Let the editors know what you think in the Mailroom.
