Jonathan Corbet, kernel developer and LWN's grumpy editor

7. 10. 2009 | Robert Krátký | Rozhovory | 4028×

1) I'm sure you've been asked this question a million times, but anyway: How did you come up with the idea of LWN?

It's sort of interesting, actually. It was not really something that we intended to do as an enterprise in its own right. In the mid-90's towards the late 90's I was working in a government research lab. And we were using Linux for a number of things, starting actually in about 1993 and going forward from there. As time went on, I was getting tired of my job 'cause I was becoming a manager and spending all my time in meetings and not doing technical stuff anymore. So, with a couple of friends, we decided to start a business and center it around Linux because it seemed very clear to us that Linux was actually going to go somewhere at the point.

So, what we started was a general consulting company in and around system implementation, system design, deployment and that kind of things. And as a way of getting started we decided to create this newsletter because we were spending a lot of time keeping up with what was going on in the Linux world, and thought that we could share that because even back then it took a fair amount of time to follow the mailing list. So we just sort of culled in all this and put it out there, as an advertisement essentially, to show the world how smart we were, so that they would come to us and engage our services for other things. Now, the consulting side of that never really worked out all that well, but the newsletter really took off.

So, after trying a couple of other things, we tried training for a while and such. And we finally kind of bowed to it and said, well, LWN seems to be where the activity is, this where we seem to be successful, so we'll do that full-time. And that's where we've been ever since.

2) How well is the subscription model working?

The subscription model is working reasonably well and we're still growing in subscribers, even now, actually, with all the economic trouble. In a sense, it doesn't work as well as we would like in that I could still be making a lot more money if I was just working as an engineer for somebody. And in fact I end up doing some consulting work here and there to kind of keep my wife happy and so on. But it's working well and getting better, and I feel pretty optimistic about it at this point. It does seem to be holding fairly solid even given the economic problems people're having. At least so far.

3) How do you balance your writing of articles and code?

Balancing is hard because there's always a thousand things I could be doing. To great extent I try to arrange things so that I can get a double value out of everything I do. So if I work on some particular piece of kernel stuff, I try to write articles about that. And certainly, just doing some kernel codework is important for the writing because that's how I stay on top of things and continue to hopefully actually know what I'm talking about. So, that's a big part of it – just trying to do dual-purpose things.

4) Your regular write ups about device drivers, programming interfaces and merged features serve as readily accessible documentation. How would you go about improving the in-kernel documentation?

How I go about it? Not as often as I should. But…

How would you go about it? Because there's been a tonne of ideas but of them really seem to catch on.

It is a very hard problem. And there are people who are trying to integrate the documentation further with the code so they're all in the same file and they will get updated together. Experience with stale comments and such in code now suggests that too may not be as successful as some people'd like.

But the real problem, I think, is that while we have hundreds or thousands of people whose job it is to write code for the kernel, there is nobody whose job it is write documentation for the kernel. None at all. Nobody is funding that activity so people are not putting their time into it. So you try to address it in other ways. Like trying to adapt rules that say code cannot be merged until the documentation has been updated. But I don't ever see that happening, honestly. You know, the documentation seems to be as good as lot of the developers want it to be, being those who already understand the things reasonably well.

Until people really decide to scratch that itch a set that goal for themselves I don't know that it's going to get a whole lot better. When somebody says 'OK, this is messed up, I'm gonna fix it' then a piece of it gets better.

5) You're doing a lot of accounting of the kernel to demonstrate the distribution and pace of the development. Based on your observation, what is the strongest and weakest point of the development process?

I think that the strong points are: that we're creating massive amounts of code. I don't think there's really any other project out there that has a code-flow at the level that the kernel does. I think it does very well at integrating the efforts of very large numbers of people. And it does very well at arbitrating the various goals that people have and making it all work together as a single coherent whole.

On the weak side, like almost every other project out there, code review is really not what it needs to be in the kernel. And a lot of the stuff goes in that really should have been caught in the review stage and made better. So, we aren't reviewing code as well we should be. That's a really hard one to fix.

6) When is the fourth edition of the O'Reilly Linux Device Drivers coming out?

I'm currently talking with the other authors about how we could write the fourth edition in a way that makes sense and doesn't fill the world with lots of obsolete printed books. I actually got an e-mail this very day (Jan 21, 2009) that O'Reilly's gonna do another printing of the third edition. I guess they sold all their copies and it is worth their while to do that. But I hate to see it because it's very obsolete at this point.

So, we're trying to talk about ways that we can do the book as a more open development process. As opposed to taking a cathedral style and sort going off and then showing it to the world when it's done. And trying to do it in a way that it's kept more current. We actually may do releases that are tied to kernel releases. So there wouldn't be a fourth edition. There would be a 2.6.35 edition maybe by the time we get it together. And we try to find a business model that makes at least a little bit of sense that goes with that. We're talking with O'Reilly about ways we can do it.

So, I don't know how that's gonna work. But I would expect that sometime during this year the work on the fourth edition will begin.

       

Komentáře

[Vlastimil Ott]

Rok?! LOL..

[frr]

V bodě 3 mi ten člověk mluví z duše. Když už strávíš 2-5 dní studiem něčeho, co nikde není pořádně v kostce popsáno, nedejbože k věci vypotíš kus kódu, tak má docela smysl strávit další 2 hodiny tím, že o tom napíšeš pár řádek které mají hlavu a patu, a vystavíš ten text někde, kde ho najde google, nebo ještě líp na nějakém obvyklém místě (LKML, /Documentation, nebo na svém ultra-slavném tématickém webu).