http://wiki.linuxformat.ru/wiki/index.php?action=history&feed=atom&title=LXF74-75%3A%D0%AD%D0%BD%D0%B4%D1%80%D1%8E_%D0%9C%D0%BE%D1%80%D1%82%D0%BE%D0%BDLXF74-75:Эндрю Мортон - История изменений2026-05-13T13:41:21ZИстория изменений этой страницы в викиMediaWiki 1.19.20+dfsg-0+deb7u3http://wiki.linuxformat.ru/wiki/index.php?title=LXF74-75:%D0%AD%D0%BD%D0%B4%D1%80%D1%8E_%D0%9C%D0%BE%D1%80%D1%82%D0%BE%D0%BD&diff=5018&oldid=prevLockal: Новая: == «Мне жаль, что Линус не использовал CVS с первого дня» == ''Официальный maintainer — хранитель ядра — расс...2008-07-11T15:19:09Z<p>Новая: == «Мне жаль, что Линус не использовал CVS с первого дня» == ''Официальный maintainer — хранитель ядра — расс...</p>
<p><b>Новая страница</b></p><div>== «Мне жаль, что Линус не использовал CVS с первого дня» ==<br />
<br />
''Официальный maintainer — хранитель ядра — рассказывает о процессе разработки и о необходимости улучшения контроля качества.''<br />
{{Врезка|Ширина=300px<br />
|Заголовок=Визитка LXF<br />
|Содержание=;Эндрю Мортон<br />
Официальный хранитель <br />
ядра Linux версии 2.6 и <br />
постоянный сотрудник OSDL <br />
ядра, Эндрю уже давно <br />
входит в узкий круг главных <br />
разработчиков ядра.<br />
*Возраст: 0x2E<br />
*Национальность: Австралиец<br />
*Использует Linux: 10 лет<br />
*Языки программирования: Молчит<br />
*Количество ПК: 20 <br />
*Дневная норма кофе: 4 чашки<br />
*Пар сандалий: 0<br />
Прямая речь: «Модель разработки с выпуском крупных релизов каждые 2-3 года просто не работоспособна.»}}<br />
<br />
Мы встретились с<br />
главным разработчиком ядра 2.6,<br />
усадили его в<br />
большое надувное<br />
кресло и попросили ответить на наши вопросы.<br />
Фактически, Эндрю Мортон является<br />
вторым человеком (после Линуса<br />
Торвальдса, конечно), на котором держится весь процесс разработки ядра<br />
Linux, так что он оказал нам бесценную помощь в проникновении на<br />
главную кухню разработчиков. Мы<br />
увидели его на OSCon 2005 и поговорили о переходе с BitKeeper, исправлении ошибок и необходимости увеличения скорости работы ядер Linux.<br />
<br />
;LXF<nowiki>:</nowiki> Переход на BitKeeper раздражал многих людей, особенно из FSF. Потом был переход на Git… Не окажется ли Git всего лишь временным решением?<br />
'''ЭМ:''' Нет, я думаю, что Git останется надолго.<br />
<br />
;LXF<nowiki>:</nowiki> Значит, Вы считаете, что Git практически вечен?<br />
'''ЭМ:''' Я предполагаю, что да. Дело в<br />
том, что цена подобного перехода<br />
слишком высока и с лихвой перекрывает все возможные выгоды.<br />
<br />
;LXF<nowiki>:</nowiki> Не думаете ли Вы, что Git должен был появиться раньше, или что с самого начала следовало бы использовать CVS?<br />
'''ЭМ:''' Ну, мы никогда не использовали<br />
CVS. Вернее, до BitKeeper мы вообще<br />
не пользовались подобными инструментами — просто была куча заплаток, которые хранились у Линуса на<br />
жестком диске, и иногда он включал<br />
их в ядро. Мы вообще никак не могли проследить, что туда попало. Помоему, это как-то не очень вежливо,<br />
и мне жаль, что Линус не использовал CVS с самого начала. Он ненавидит CVS, потому что имел с ним проблемы, однако я считаю, что для<br />
простой линейной модели развития<br />
использование CVS было оправдано,<br />
да и появилась бы история<br />
изменений.<br />
<br />
Я думаю, главная заслуга<br />
BitKeeper — в том, что Линус вообще<br />
стал хоть чем-то пользоваться. При<br />
любой другой свободной системе<br />
контроля версий мы все равно прошли бы 90 % пути. Просто BitKeeper<br />
был тогда лучшей подобной системой<br />
и подходил под наш процесс разработки. Я и сам чувствовал себя некомфортно, используя BitKeeper — естественно, из-за его проприетарности, но<br />
с этим жить можно. В конце концов,<br />
моя главная задача — улучшение ядра,<br />
а не… э-э… религиозный фанатизм.<br />
Я всегда ждал, что конец будет<br />
плачевным и BitKeeper откинет колеса.<br />
Переход оказался более резким, чем<br />
я рассчитывал, но мы довольно легко<br />
вышли из неприятной ситуации.<br />
<br />
;LXF<nowiki>:</nowiki> Показал ли BitKeeper широкой общественности, как надо работать? Ведь благодаря ему Вы и перешли на Git, вместо того, чтобы вернуться к старой модели получения заплаток по электронной почте. Правда, что он создал такие преимущества, без которых люди теперь не могут обойтись?<br />
'''ЭМ:''' Да, конечно, мы теперь не сможем жить без системы контроля версий и ни за что не вернемся к старой<br />
модели разработки, которая существовала до BitKeeper. Все очень оценили его удобства.<br />
<br />
;LXF<nowiki>:</nowiki> Наверняка ускорилось внедрение исправлений.<br />
'''ЭМ:''' Так говорят… Скорее, это облегчило работу Линусу — система контроля версий позволяет ему доверять<br />
людям. Например, если Грег КроаХартман (Greg Kroah-Hartman) вышлет<br />
ему серию заплаток со словами<br />
«наложите, пожалуйста, их на ядро»,<br />
то он просто поверит Грегу и сделает<br />
это. Раньше, когда у нас не было системы контроля версий, Линус тщательно вчитывался в каждую строку<br />
присланного кода — в итоге получилось косвенное улучшение производительности! Что бы мы ни использовали как систему контроля версий,<br />
необходимость перемен в ядре оказывает все более настоятельное давление. Появилось много новых<br />
талантливых разработчиков, уровень<br />
разработок растет, скорость изменений уже пробила крышу.<br />
Может, мы справились бы и без<br />
всяких систем контроля версий, но<br />
счастливы, что нам не нужно этого<br />
делать.<br />
<br />
;LXF<nowiki>:</nowiki> Вы сказали, что число разработчиков постоянно растет. Однако создается впечатление, что и журнал изменений в каждой новой версии все больше. Я просмотрел 2.6.2 (287К), 2.6.4 (322К), 2.6.6 (487К), 2.6.8 (883К), 2.6.10 (1.5МБ)…<br />
'''ЭМ:''' Каждый новый журнал включает<br />
в себя все старые, но в общем это<br />
действительно так.<br />
;LXF<nowiki>:</nowiki> Это отражает повышение скорости разработки?<br />
'''ЭМ:''' В некоторой степени да. Раньше<br />
выпуски появлялись один за другим,<br />
а в последнее время мы несколько<br />
снизили частоту. Но сама разработка<br />
медленнее не стала.<br />
;LXF<nowiki>:</nowiki> Я заметил, что в журнале изменений есть позиция «Signed off by» — «Подписано таким-то». Зачем это нужно?<br />
'''ЭМ:''' Это своеобразный способ избавиться от «глупостей» SCO. Люди<br />
хотели иметь возможность разобраться, откуда взялись конкретные участки кода. Нам и самим, независимо от<br />
них, казалось, что неплохо бы знать,<br />
кто прислал «кривой» код. Таким<br />
образом, мы приняли простое соглашение: каждый, кто предложил какуюто заплатку, должен подписать ее<br />
своим прозвищем. «Подписано» значит, что автор читал «Сертификат об<br />
источнике» (Developer’s Certificate of<br />
Origin), который содержится в документации ядра, и согласен с ним.<br />
;LXF<nowiki>:</nowiki> Значит, эта надпись говорит не о качестве кода, а лишь сообщает, что<br />
«я верю, они это сами написали»?<br />
'''ЭМ:''' Да, так и есть. Эта надпись говорит «я написал этот код сам, я подтверждаю, что не стырил его из какой-нибудь UnixWare или другой системы».<br />
И каждый, кто присылает заплатки,<br />
обычно добавляет подобную подпись.<br />
Есть еще гриф «Ackd by».<br />
;LXF<nowiki>:</nowiki> А это что значит?<br />
'''ЭМ:''' Это значит «Одобрено», для случаев, когда кто-то просто проверил<br />
чей-то код, но ничего в нем не менял.<br />
Вообще-то это предназначено для<br />
хранителей-maintainer’ов, которые<br />
хотят подчеркнуть, что заплатка<br />
проверена.<br />
;LXF<nowiki>:</nowiki> Видимо, модель разработки стабильных версий ядра 2.6 тоже изменится. В прошлом году нам показалось, что в ядро попадают и нестабильные куски кода, о которых должны позаботиться разработчики дистрибутивов.<br />
'''ЭМ:''' Да, так оно и было.<br />
LXF: Теперь же есть двухнедельное<br />
«окно», в ядро включается только то,<br />
что было дописано, что готово на<br />
данный момент.<br />
'''ЭМ:''' Ох, тут моя вина. Я выступил с<br />
речью насчет этого на встрече разработчиков ядра. Я не считаю, что на<br />
сегодняшний день качество кода ядра<br />
стоит на должной высоте. В каждой<br />
новой версии приходится возвращаться к ошибкам прошлых.<br />
Предполагалась такая модель: в<br />
день, когда Линус решает выпустить<br />
новую версию, все хранители подсистем, а их 50-70 человек, принимаются включать весь накопившийся<br />
материал, причем в идеале обязаны<br />
уложиться в недельный срок (самая<br />
активная бомбежка заплатками происходит в первую неделю после<br />
выпуска). Еще неделю я сливаю все<br />
заплатки в свое дерево, и следующие<br />
четыре недели мы стабилизируем<br />
изменения, отлавливаем ошибки и<br />
так далее. Пока мы этим занимаемся, люди работают над новым функционалом для следующего цикла.<br />
В общем, это похоже на конвейер.<br />
Так было задумано.<br />
Фактически же, люди непрерывно<br />
присылают что-то новое. В прошлый<br />
раз, например, нам пришлось капитально обновлять аудиодрайвер спустя всего четыре недели после выпуска<br />
2.6.12. И все из-за плохой синхронизации, потому что здоровенный кусок<br />
кода куда-то потерялся за то время,<br />
когда шла проверка стабильности.<br />
Мы хотим, чтобы хранители подсистем работали в более тесной связке с<br />
разработчиками ядра.<br />
;LXF<nowiki>:</nowiki> Вы сказали, что скорость разработки ядра постоянно растет, а по моим наблюдениям, промежуток времени между выходом новых версий ядра увеличивается. Может быть, развелось слишком много хранителей ядра, которые почем зря закидывают вас заплатками?<br />
'''ЭМ:''' Главное, слишком много кода -<br />
время уходит на его проверку, доработку, тестирование. Бывает, большие куски кода доходят с опозданием: если доработанная SCSI-подсистема попадает к нам на 5-й неделе,<br />
мы не в состоянии выпустить устойчивое ядро со всеми изменениями,<br />
уложившись в график. Нужно же все<br />
«обкатать»!<br />
;LXF<nowiki>:</nowiki> У Вас существует плановая периодичность выпуска ядра?<br />
'''ЭМ:''' Нет, мы их выпускаем, когда они<br />
кажутся нам рабочими, хотя многим<br />
хотелось бы видеть новые версии<br />
почаще. Я думаю, нам по силам обеспечить периодичность в два — два с<br />
половиной месяца. Возможно, комуто кажется, что это долго. Я не хотел<br />
бы превышать двухмесячный период.<br />
;LXF<nowiki>:</nowiki> Когда Торвальдс объявил, что будет работать на PowerPC, он назвал Power 5 и ЭМD64 двумя самыми перспективными архитектурами. Вы согласны с этим заявлением?<br />
'''ЭМ:''' Ну, в общем, x86 уже не тот, что<br />
раньше; а вот c x86-64 все<br />
хорошо. Люди просто принимают слишком близко к сердцу, какая именно машина<br />
в данный момент у Линуса на<br />
столе. Я не думаю, что это<br />
так важно. У него хватает<br />
компьютеров x86 для<br />
тестирования.<br />
;LXF<nowiki>:</nowiki> Он теперь переехал в Портленд — наверное, тяжело жить так далеко от него, по сравнению с былыми днями?<br />
'''ЭМ:''' Фактически, мы жили на расстоянии 20 минут: он — в Сан-Хосе, а я -<br />
в Пало-Альто. А лично встречались<br />
тогда всего два раза.<br />
;LXF<nowiki>:</nowiki> Если говорить о вещах, которые сейчас на слуху, вроде Xen или Inotify — Вы находите их интересными?<br />
'''ЭМ:''' Ну, Xen, очевидно, очень нужен<br />
многим. Я не склонен что-либо предусматривать только потому, что люди<br />
нам это присылают. Принятие решения о нововведениях в ядро происходит коллегиально. Мы с Линусом не<br />
бросаем клич вроде «Эй, нам нужны<br />
x, y и z в третьем квартале 2006-го<br />
года».<br />
<br />
Если какой-нибудь группе требуются специфические изменения<br />
в ядре, они выпускают свою версию,<br />
а не ждут, пока мы включим эти<br />
заплатки в основную ветвь.<br />
<br />
А что в будущем? [напомним, интервью бралось на конференции OSCon осенью 2005 года, — прим.ред.] FUSE мы<br />
скоро поместим, очень многим это<br />
понравится. Кластерную файловую<br />
систему OCFS планируем включить в<br />
ядро 2.6.14. Кластеры — довольно<br />
обширная тема, мы потратили на нее<br />
много лет.<br />
<br />
Существует масса кластерных<br />
проектов, но все они слишком разные,<br />
и их разработчики никак не могут<br />
найти точек соприкосновения и договориться. OCFS же выглядит готовым<br />
решением, и нет никаких препятствий<br />
включению его в ядро. Я отнюдь не<br />
уверен, что со штуками вроде Red Hat<br />
GFS будет так же легко.<br />
Ну что еще.. не знаю, что вам сказать. Какие нам коды люди пришлют,<br />
такие и будем внедрять.<br />
;LXF<nowiki>:</nowiki> Как долго код из Вашего mmдерева добирается до официальной версии ядра Линуса?<br />
'''ЭМ:''' Всякое бывает. По большому счету, мой код и есть то самое ядро,<br />
которое выйдет через несколько<br />
месяцев, за вычетом определенных<br />
кусков. Я вставляю в него всевозможные заплатки, тестирую, и, возможно,<br />
отсылаю Линусу, когда считаю, что<br />
все готово. Естественно, расхождения<br />
накапливаются.<br />
Например, на сегодняшний день<br />
в моем ядре есть файловая система<br />
Reiser4, это около 2-х мегабайт, и<br />
несколько других интересных функций. Они не влияют на идеологию<br />
ядра, просто добавляют какие-то<br />
функции, но это большие куски кода.<br />
;LXF<nowiki>:</nowiki> Над чем лично вы сейчас работаете? Например, вы еще используете какой-нибудь DDE?<br />
'''ЭМ:''' Боюсь, что да. Я давненько не<br />
занимался пользовательским пространством, вожусь с дурацким<br />
скриптом управления патчами.<br />
;LXF<nowiki>:</nowiki> Вы тратите 12-14 часов в сутки на работу с ядром?<br />
'''ЭМ:''' Да, тестирую новые патчи,<br />
исправляю ошибки и т. д. Связываюсь<br />
с другими разработчиками. На борьбу<br />
с ошибками уходит довольно много<br />
времени.<br />
;LXF<nowiki>:</nowiki> На исправление ошибок?<br />
'''ЭМ:''' Скорее, на выяснение информации об ошибке. Иногда отчеты об<br />
ошибке (а это очень ценная вещь)<br />
присылаются довольно бестолковые — приходится вступать в диалог с<br />
отправителем, чтобы разобраться.<br />
Причем я всегда стараюсь найти автора проблемного кода. Вот прямо сейчас мы работаем над rc5 ядра, где<br />
ничего особенного добавлено не<br />
было — сплошные исправления<br />
ошибок.<br />
;LXF<nowiki>:</nowiki> Таким образом, это почти маркетинг ошибок, их пропаганда…<br />
'''ЭМ:''' До известной степени да, равно<br />
как и социальная инженерия.<br />
;LXF<nowiki>:</nowiki> Так получается потому, что некоторые хранители поддерживают свои части ядра лишь из уважения к Вам?<br />
'''ЭМ:''' Ну, порой этих хранителей приходится стыдить. Хотя вообще-то надо<br />
бы им посочувствовать. Большинство<br />
сбоев возникает на уровне драйверов,<br />
и хранители не могут воспроизвести<br />
их. Вот основная проблема. Поэтому<br />
приходится долго и сложно вести<br />
переговоры с человеком, который<br />
сообщил про данный сбой, разбираться, что именно произошло, просить<br />
его ставить на заплатку другие<br />
заплатки и выполнять одно, другое,<br />
третье… Получается удаленная отладка. Хлопот немало.<br />
;LXF<nowiki>:</nowiki> Кроме ядра, есть ли другие проекты, которые Вам интересны и над которыми Вы хотели бы работать?<br />
'''ЭМ:''' Я немного соскучился по<br />
написанию кода; думаю, когда я<br />
почувствую, что не справляюсь с<br />
работой, я передам обязанности<br />
кому-нибудь другому, а сам вернусь к поддержке своего конкретного кусочка ядра.<br />
;LXF<nowiki>:</nowiki> Вы сейчас на «острие прогресса» ядра. Когда появится версия 2.7, будете ли Вы продолжать развивать линейку 2.6, или передадите ее кому-нибудь другому, а сами будете готовить 2.8?<br />
'''ЭМ:''' Поживем — увидим. Многое будет<br />
зависеть от причин для выпуска 2.7; я<br />
пока не представляю, какими они<br />
будут. Одна из возможных причин -<br />
неудовлетворенность качеством ядер<br />
2.6. Но я думаю, что ветви 2.6 еще<br />
есть куда расти.<br />
;LXF<nowiki>:</nowiki> Что Вы намерены делать дальше?<br />
'''ЭМ:''' Вероятно, я в том или ином качестве буду работать над Linux — скорее<br />
всего, до конца своей карьеры.</div>Lockal