Jonathan Corbet, vývojář jádra a autor LWN.net

7. 10. 2009 | Robert Krátký

Články - Jonathan Corbet, vývojář jádra a autor LWN.net  

Jonathan Corbet vede redakci stránek LWN.net, píše množství článků o vnitřnostech linuxového jádra, často po celém světě přednáší o stavu jaderného vývojového procesu a v neposlední řadě také aktivně přispívá kódem do jádra. V rozhovoru mluví mimo jiné o tom, jak tak trochu mimochodem vznikly stránky LWN.net, jak se mu daří skloubit psaní technických textů s vlastním programováním, a co považuje za nejsilnější a nejslabší články vývojového modelu linuxového jádra.

Rozhovor vznikl po Jonově přednášce na Linux.conf.au 2009 v tasmánském Hobartu. Bohužel mi trvalo skoro rok, než jsem jej konečně převedl „na papír“, za což se omlouvám. Naštěstí je téma rozhovoru z většiny nadčasové.

---

1) Je mi jasné, že už se vás na to ptali mockrát, ale přesto: Jak jste přišel na myšlenku LWN?

Jonathan Corbet: Vlastně je to docela zajímavé. Nebylo to něco, co bychom bývali zamýšleli jako samostatný podnik. V polovině a ke konci 90. let jsem pracoval ve vládní výzkumné laboratoři, kde jsme Linux používali k mnoha věcem. Začali jsme s ním kolem roku 1993. Jak šel čas, přestávala mě moje práce bavit, protože se ze mě stával manažer a více času jsem trávil na poradách než řešením technických záležitostí. Proto jsme se s pár přáteli rozhodli, že založíme firmu a postavíme ji kolem Linuxu, protože nám tenkrát připadalo zřejmé, že má Linux budoucnost.

Takže jsme začali provozovat obecné poradenství týkající se implementací a návrhů systémů apod. A abychom to rozjeli, rozhodli jsme se vytvořit zpravodaj (newsletter). Stejně jsme trávili hodně času tím, že jsme sledovali, co se ve světě Linuxu děje, a tak jsme se o to podělili, protože už tehdy bylo sledování vývojářské konference dost časově náročné. Dali jsme to tedy dohromady a vystavili, v podstatě jako reklamu, abychom světu ukázali, jak jsme dobří, takže by za námi přišli a najali si nás na jiné věci. Jenže ta konzultační část podnikání nikdy nevyšla, ale zpravodaj se výborně ujal.

Zkusili jsme pak ještě pár dalších věcí, chvíli to bylo školení. Až jsme nakonec museli uznat, že na LWN se toho děje nejvíc, tam leží náš úspěch, takže to budeme dělat naplno. A tak je to doposud.

2) Jak dobře funguje model založený na předplatném?

Předplatné funguje rozumně dobře a stále se zvětšuje počet předplatitelů – i nyní, když se lidé potýkají s ekonomickými obtížemi. V jistém smyslu nefunguje natolik dobře, jak bychom si přáli, protože bych stále mohl vydělávat mnohem více, kdybych pro někoho pracoval jako inženýr. A konec konců, občas stejně poskytuji nějaké konzultace, abych trochu usmířil manželku atd. Ale funguje to dobře a stále se to zlepšuje, takže jsem v tuto chvíli optimista. A drží se to i navzdory ekonomickým potížím, které lidé mají. Alespoň prozatím.

3) Jak se vám daří skloubit psaní článků a kódu, programování?

Nacházení rovnováhy je obtížné, protože vždycky existuje spousta věcí, které bych mohl dělat. Z velké míry se snažím činnosti naplánovat tak, abych mohl z jedné věci vytěžit dvojnásobek. Takže pokud pracuji na určité části jádra, také o tom zkouším sepsat článek. Kromě toho je programování jádra důležité už proto, abych si udržel přehled a i nadále, doufejme, věděl, o čem mluvím.

4) Vaše pravidelné popisy ovladačů zařízení, programovacích rozhraní a začleněných vlastností slouží jako snadno přístupná dokumentace. Jak byste řešil zlepšení dokumentace obsažené v jádře?

Jak ji zlepšuji? Ne tak často, jak bych měl. Ale…

Co byste navrhl pro zlepšení? Objevilo už se množství nápadů, ale žádný se pořádně neujal.

To je velmi složitý problém. Někteří lidé se snaží zařadit dokumentaci přímo ke kódu, aby bylo vše v jediném souboru. Takže by byly aktualizovány společně. Máme však zkušenosti se zastaralými komentáři, které naznačují, že ani tento způsob nefunguje tak dobře, jak by si jeho zastánci přáli.

Ale skutečný problém je podle mého v tom, že zatímco máme stovky nebo možná tisíce lidí, kteří jsou placeni za programování jádra, nikdo není placen za psaní dokumentace. Takovou aktivitu nikdo nefinancuje, takže se jí lidé nevěnují. Snažíme se to tedy řešit jinými způsoby. Například zaváděním pravidel, že kód nebude začleněn, dokud nebude aktualizována dokumentace. Avšak to se, upřímně, moc nedaří. Dokumentace je totiž dobrá natolik, aby s ní byli spokojeni vývojáři, kteří však už věcem docela dobře rozumí.

Dokud to někoho nezačne trápit a nestanoví si to jako cíl, neřekl bych, že se situace nějak zlepší. Až někdo řekne „OK, tohle je potřeba dát do pořádku, tak se do toho pustím“, tak se to zlepší.

5) Zpracováváte hodně statistik, abyste mohl předvést, jak je rozdělen a jak je rychlý vývoj jádra. Co je podle vás nejsilnější a nejslabší bod vývojového procesu?

Silné body podle mě jsou: Vytváříme obrovské množství kódu. Nevím o tom, že by existoval jakýkoliv jiný projekt, ve kterém by kód proudil tolik jako u jádra. Vývojový proces také velmi dobře spojuje úsilí velkého počtu lidí. A kromě toho je vývojový proces dobrý v tom, jak slaďuje různé cíle a vytváří z toho všeho jednotný a smysluplný celek.

Naše slabost, podobně jako u skoro každého projektu, je kontrola kódu. Do jádra se dostává spousta věcí, které měly být zachyceny během kontroly kódy a vylepšeny. Neprovádíme tedy kontrolu kódu tak, jak bychom měli. Ale je těžké to napravovat.

6) Kdy vyjde čtvrté vydání knihy „Linux Device Drivers“ (O'Reilly)?

V tuto chvíli mluvím s ostatními autory (Alessandro Rubini a Greg Kroah-Hartman, pozn. red.) o tom, jak tu knihu napsat, aby to dávalo smysl, abychom nepřidávali další papírovou knihu se zastaralými informacemi. Zrovna dnes jsem dostal e-mail o tom, že O'Reilly chystá další tisk třetího vydání. Patrně vyprodali všechny výtisky, takže jim to stojí za to. Ale mě to štve, protože už je ta kniha v současné době velmi zastaralá.

Proto přemýšlíme, jak z toho psaní udělat otevřenější proces. Místo abychom to brali jako katedrálu, zavřeli se s knihou někam stranou a světu ukázali až dokončené dílo. Snažíme se najít způsob, jak to udržovat aktuálnější. Možná nakonec budeme dělat vydání svázaná s vydáváním nových verzí jádra. Tak by nebylo čtvrté vydání, ale vydání 2.6.35, než se dostaneme k tomu, abychom to nějak dali dohromady. A také se snažíme najít obchodní model, který by s něčím takovým dával aspoň trochu smysl, a mluvíme o tom s O'Reilly.

Nevím tedy, jak to dopadne. Ale řekl bych, že v průběhu tohoto roku práce na čtvrtém vydání započne.

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.