📄 00000096.htm
字号:
<HTML><HEAD> <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人: lizp (Soaring Bird), 信区: Linux <BR>标 题: LWN Interviews Alan Cox <BR>发信站: BBS 水木清华站 (Thu Jan 28 16:17:14 1999) <BR> <BR>LWN interviews Alan Cox <BR> <BR> Alan Cox is a name that should be well known to most Linux users. He is responsible for <BR> much of the code in the Linux kernel, including small pieces like networking and SMP. <BR> He has handled the latter-day 2.0 releases, and serves as one of the primary conduits for <BR> patches into the current development kernels. He is certainly one of the key players in the <BR> kernel development arena. <BR> <BR> We thank Alan for taking time out of his busy schedule to answer a few questions. <BR> <BR> LWN: 2.2.0 has been a long time in coming. Too long, perhaps? Do you think the 2.3 <BR> series will be shorter? <BR> <BR> AC: I hope so - I'd like to see 2.4 being out early 2000 but it depends entirely on Linus. I do think there is a <BR> general desire for a much shorter turn around time for 2.4. <BR> <BR> LWN: What are the most interesting things that will happen in the 2.3 series? <BR> <BR> AC: I'm not actually sure. It's possible to predict some things by looking at patches that are pending post 2.2 <BR> or in progress. The clear ones are 64bit file support, probably 32bit uid support and support for very large <BR> numbers of processes. On the device side, I'm expecting I2O and USB to be in 2.3. I'd hope the PCI <BR> bus/PCMCIA/Cardbus/Hotswap clean ups that need to be done occur. That actually has scope to reduce <BR> kernel complexity rather than increase it, which is a good sign. <BR> <BR> I'm not sure a lot will happen in the networking arena that is visible to end users - addition of DECnet isn't <BR> like to be a major win to the average user. ATM might well be more visible and it is about time it got in. <BR> <BR> I'm looking forward to all the palmtop support being folded in - there are several strands here and all of them <BR> are beginning to show clear unified needs. <BR> <BR> LWN: You seem to have taken on an increasingly organizational role in the kernel development process. <BR> Does that sit well with you, or would you rather get back to more full-time hacking? <BR> <BR> AC: It just sort of happened. I'm anticipating the amount of co-ordination will go down again now that 2.2 is <BR> basically sorted out. I hope so anyway as I want to get the I2O code finished, debug the 3c527 ethernet driver I <BR> am writing and use the work the vMac people have done to attempt to get palette loading and floppy disks <BR> working on the Macintosh 68K. <BR> <BR> LWN: And how do you manage to process (and produce) all that mail every day and still get something <BR> done? <BR> <BR> AC: That is actually fairly easy. I've always been a fast reader and most of the stuff I dig through requires <BR> little in the way of a reply - a lot of the mail I send is just pointing people at each other to avoid duplication of <BR> work. Much of the rest is tracking bugs and patches. <BR> <BR> All the patch merging and bug chasing is getting something done, so the mail scanning is definitely not time <BR> wasted. <BR> <BR> LWN: Kernel development over the past year has been interrupted occasionally by "Linus burnout" episodes. <BR> What are your thoughts on the sustainability of the current development model? Is there anything you would <BR> change? <BR> <BR> If I was the kernel organiser, there are quite a few things I'd do differently. Right now Linus applies all the <BR> patches and builds the trees, I'd much rather there were a group of people directly merging patches into the <BR> kernel tree and Linus sitting watching it and vetoing things rather than doing all the merge work, too. <BR> <BR> The model has changed over 2.1.x and it has evolved to a kind of compromise that seems to work very well. <BR> Linus is still applying all the patches but there are people now collating and feeding Linus tested sets of <BR> patches in small cleanly organised groups. Larry McVoy's new version control toys may solve some of the <BR> remaining problems. <BR> <BR> LWN: Do you anticipate taking on responsibility for the 2.2 series like you have with 2.0, or will somebody <BR> else have to step up for that one? <BR> <BR> AC: I never really anticipated it with 2.0.x; it simply happened because I was collating all the patches. My <BR> guess is that, by the time 2.2 gets into that long term maintenance state, 2.0.x will be basically dead. <BR> <BR> LWN: If you were to point at the biggest unmet need in the Linux world, the project most in need of <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -