📄 00000278.htm
字号:
<HTML><HEAD> <TITLE>BBS水木清华站∶精华区</TITLE></HEAD><BODY><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>发信人: linuxrat (叫我老鼠错不了), 信区: Linux <BR>标 题: 咱们来看看LWN采访Alan Cox的记录吧. <BR>发信站: BBS 水木清华站 (Thu Dec 30 20:23:56 1999) <BR> <BR> 呵呵, 国内很少报道Alan Cox先生的哦. 我自己把Alan Cox看成是Linux内核开发 <BR> 小组的第二把手, 各位呢? 我听说过Alan Cox的一个小故事, 是关于他在内核小 <BR> 组邮递列表当中说"Linus跟本不懂Linux"的话. 我看了Alan Cox的照片, cool呆了. <BR> (Origin URL: <A HREF="http://lwn.net/)">http://lwn.net/)</A> <BR>=============Begin of Interview with Alan Cox==================== <BR>LWN interviews Alan Cox <BR> <BR> Alan Cox Alan Cox is a name that should be well known to most Linux <BR> users. He is responsible for much of the code in the Linux kernel, <BR> including small pieces like networking and SMP. He has handled the <BR> 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 <BR> the key players in the kernel development arena. <BR> <BR> We thank Alan for taking time out of his busy schedule to answer a few <BR> questions. <BR> <BR> LWN: 2.2.0 has been a long time in coming. Too long, perhaps? Do you <BR> think the 2.3 series will be shorter? <BR> <BR> AC: I hope so - I'd like to see 2.4 being out early 2000 but it <BR> depends entirely on Linus. I do think there is a general desire for a <BR> much shorter turn around time for 2.4. <BR> <BR> LWN: What are the most interesting things that will happen in the 2.3 <BR> series? <BR> <BR> AC: I'm not actually sure. It's possible to predict some things by <BR> looking at patches that are pending post 2.2 or in progress. The clear <BR> ones are 64bit file support, probably 32bit uid support and support <BR> for very large numbers of processes. On the device side, I'm expecting <BR> I2O and USB to be in 2.3. I'd hope the PCI bus/PCMCIA/Cardbus/Hotswap <BR> clean ups that need to be done occur. That actually has scope to <BR> reduce kernel complexity rather than increase it, which is a good <BR> sign. <BR> <BR> I'm not sure a lot will happen in the networking arena that is visible <BR> to end users - addition of DECnet isn't like to be a major win to the <BR> average user. ATM might well be more visible and it is about time it <BR> got in. <BR> <BR> I'm looking forward to all the palmtop support being folded in - there <BR> are several strands here and all of them are beginning to show clear <BR> unified needs. <BR> <BR> LWN: You seem to have taken on an increasingly organizational role in <BR> the kernel development process. Does that sit well with you, or would <BR> you rather get back to more full-time hacking? <BR> <BR> AC: It just sort of happened. I'm anticipating the amount of <BR> co-ordination will go down again now that 2.2 is basically sorted out. <BR> I hope so anyway as I want to get the I2O code finished, debug the <BR> 3c527 ethernet driver I am writing and use the work the vMac people <BR> have done to attempt to get palette loading and floppy disks working <BR> on the Macintosh 68K. <BR> <BR> LWN: And how do you manage to process (and produce) all that mail <BR> every day and still get something done? <BR> <BR> AC: That is actually fairly easy. I've always been a fast reader and <BR> most of the stuff I dig through requires little in the way of a reply <BR> - a lot of the mail I send is just pointing people at each other to <BR> avoid duplication of work. Much of the rest is tracking bugs and <BR> patches. <BR> <BR> All the patch merging and bug chasing is getting something done, so <BR> the mail scanning is definitely not time wasted. <BR> <BR> LWN: Kernel development over the past year has been interrupted <BR> occasionally by "Linus burnout" episodes. What are your thoughts on <BR> the sustainability of the current development model? Is there anything <BR> you would change? <BR> <BR> AC: If I was the kernel organiser, there are quite a few things I'd do <BR> differently. Right now Linus applies all the patches and builds the <BR> trees, I'd much rather there were a group of people directly merging <BR> patches into the kernel tree and Linus sitting watching it and vetoing <BR> 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 <BR> compromise that seems to work very well. Linus is still applying all <BR> the patches but there are people now collating and feeding Linus <BR> tested sets of patches in small cleanly organised groups. Larry <BR> McVoy's new version control toys may solve some of the remaining <BR> problems. <BR> <BR> LWN: Do you anticipate taking on responsibility for the 2.2 series <BR> like you have with 2.0, or will somebody else have to step up for that <BR> one? <BR> <BR> AC: I never really anticipated it with 2.0.x; it simply happened <BR> because I was collating all the patches. My guess is that, by the time <BR> 2.2 gets into that long term maintenance state, 2.0.x will be <BR> basically dead. <BR> <BR> LWN: If you were to point at the biggest unmet need in the Linux <BR> world, the project most in need of volunteers currently, which would <BR> that be? <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -