13 ноября на портале The H-Online появилось интервью создателя ядра Linux Линуса Торвальдса. Линус рассказал об этапах большого пути к современному состоянию ядра и своей работе в коллективе, поведал об особенностях организации ядра для мобильных устройств и серверов (даже сообщил, что в них много общего), ответил на вопросы о вовлеченности в процесс разработки гигантов IT-индустрии, и о том, чем ему нравится заниматься, а чем — нет.
 

Линус Торвальс: "Я больше не читаю код" с Glyn Moody

Мне очень повезло побеседовать с Линусом еще в ранний период истории развития Linux, еще в 1996 году, когда он еще жил в Хельсинки (вы можете познакомиться с тем интервью в одном из страх выпусков Wired). Тот период был крайне важным в его жизни, и в личном плане - тогда у него родился первый ребенок - и в плане карьеры. Он планировал устроиться в компанию разработки микрочипов Transmeta, однако этот шаг себя не оправдал, хотя помог ему перебраться в США, где он проживает сейчас.
 
В Европе он теперь бывает довольно редко, и я решил воспользоваться удобным случаем застать его в Барселоне на недавнем LinuxCon Europe 2012, чтобы побеседовать с ним снова и обсудить ключевые моменты разработки ядра и жизни сообщества вокруг его.
 
Glyn Moody: Обращаясь к последним пятнадцати лет разработки ядра, какие ключевые события в его истории вы могли бы выделить?
 
Linus Torvalds: Основная и наиважнейшая для меня вещь - эта вся проделанная нами работа над масштабированием системы. Мы начинали с уверенной работы на 2 или 4 процессорах, а сейчас вы можете установить хоть 4000 - конечно, масштабирование будет неидеальным, но в большинстве случаев причиной тому будет явно не ядро. Если ваши процессы работают адекватно, то и масштабирование также произойдет адекватно. На это и потребовались серьезные усилия.
 
В частности, SGI долго разрабатывали возможность масшатбирования на несколько сотен ядер. Мы просто не могли принять их первоначальные пачти к ядру. В них не было никакого смысла на обычных компьютерах, так как вся дополнительная инфраструктура была нацелена на тысячи яде. Для самых распространенных конфигурация с 2 ядрами это было бы чересчур.
 
Я очень долго боялся, что у нас получается высокопроизводительное ядро для мощных машин, исходный код которого частично отделен от кода основной части обычного ядра. Было приложено очень много усилий ради того, чтобы получить понятную кодовую базу, для которой перед компиляцией можно указать: эй, мне нужно, чтобы ядро работало на 4000 ядрах, и которая бы сгенерировала код для этого случая. В то же время, если бы вы сказали: нет, мне нужно ядро для работы на двух ядрах, другое ядро собралось бы из того же исходного кода.
 
Именно эта работа, как я теперь вижу, оказалась крайне важной, поскольку мы на самом деле очень сильно улучшили код. Все, что для унификации кода сделали SGI и другие, было по большому счету глобальной уборкой - если что-то не работает для сотни ядер, то нужно вычистить из этого участка неподходящий код или доработать его. Эти труда помогли сделать ядро гораздо более удобным в плане поддержки. Сейчас на персональных компьютерах обычное дело иметь 8 или 16 ядер; раньше у нас могли бы появиться проблемы при масштабировании на 8 ядер, а сейчас это проще простого.
 
Но кроме этого есть и другие важные свершения. Опять же, несколько лет люди из мира телефонов были так требовательны в плане потребления энергии, что им приходилось прибегать к грязным хакам, особенно на ARM-е, чтобы сэкономить еще немного энергии. Мы потратили годы на общие механизмы регулирования энергопотребления, делая по сути то же - вместо вставки хаков специально для ARM или еще нескольких телефонных архитектур, мы просто задействовали его глобально для всего ядра. Эта работа заняла пять лет, но теперь ее результаты заметны на любом устройстве.
 
Довольно часто добавление нового поддерживаемого устройства никак не отражается на самом ядре, но вопрос энергопотребления затронул тысячи имеющихся драйверов устройств. Он повлиял на функциональность ядра, например, выполняя отключение ядер, повлиял на планировщики, на виртуальные машины, на все.
 
Однако дело здесь не только во влиянии, а еще и в потенциальной угрозе все сломать, что ставит нас в рискованное положение. Мы столько времени потратили, продвигаясь на два шага вперед и на один назад, так как наше улучшение оказалось настолько весомым, что поломало все устройства. Тогда мы сделали шаг назад и стали исправлять все ошибки.
 
Действительно, каждый релиз, по большому счету, - это обновление драйверов. И это очень скучно, ведь нет ничего особо интересного в драйвере, он просто добавляет еще один поддерживаемый чипсет или что-то еще, хотя с другой стороны это наш хлеб. Более половины ядра - это просто драйверы, поэтому все захватывающие исследования и нововведения в конце концов почти незаметны за работой по поддержке нового железа.
 
Glyn Moody: Какие основные изменения вы внесли в архитектуру при добавлении новых поддерживаемых устройств?
 
Linus Torvalds: USB-стек уже пару раз был полностью переписан просто потому, что появлялись новые области применения и мы понимали - ой, наш USB-стек никогда не принимал это во внимание и работать он не будет. Так, USB 3.0 требует поддержки нового хост-контроллера, и по всей видимости он мало похож на прежнюю реализацию, то есть на требуется изменить базовую его часть, чтобы иметь возможность работать с разными версиями стандарта USB. А ведь это происходит не только с USB, а еще с PCI, который потом становится PCIe и добавляет поддержку подключения на горячую.
 
Еще еще одно большое отличие между традиционным Linux и традиционным Unix. У вас есть рабочая машина с Unix, вы загружаетесь и работаете, и ничего не изменяется - вы не добавляете новых устройств. Сейчас люди жить не могут без USB, хотя дело не только в этом. Вся концепция горячего подключения устройств подразумевает очень и очень масштабные фундаментальные изменения архитектуры, которые мы должны реализовать.
 
Glyn Moody: А как обстоят дела с сообществом вокруг ядра – какого его участие?
 
Linus Torvalds: Раньше оно было гораздо меньше. Не знаю, когда произошел большой сдвиг, но раньше все сообщество составляли я и еще 50 разработчиков, не было глубокой иерархии. Сейчас приходящие ко мне патчи проходят через четыре уровня проверки. Мы выпускаем новый релиз каждые три месяца, и в каждый из них вовлечено по тысяче человек. При это 500 человек из этой тысячи присылают патчи в одну строку, исправляющие что-то очень явное - вот как они работают. Причем многие их них не сделали больше ничего, и это хорошо. Но когда в проект вовлечены тысяча человек, особенно когда некоторые из них присылают лишь одну строчку, меня одного просто не хватит на проверку каждого патчей по отдельности. У меня тогда не останется времени общаться с людьми.
 
Некоторые мои разработчики прямо специализируются на драйверах, при этом у них есть коллеги, которые хорошо разбираются в каком-либо конкретном вопросе касательно драйверов, и именно эти люди общаются с теми, кто присылает свои драйверы или патчи к ним. К тому времени, когда патч доходи до меня, его уже просмотрят несколько пар глаз, обычно четыре, хотя довольно часто эту процедуру выполнят два человека совместно.
 
Glyn Moody: И как это сказывается на вашей роли в проекте?
 
Linus Torvalds: Ну, самое главное - это то, что я больше не читаю код. Когда патч прошел через двух человек, то после них я могу либо взглянуть на него и сказать: нет, все это написано зря, и разбираться уже на этом этапе, но, честно говоря, мне не нравится такой подход и у меня нет времени на это.
 
В основном, когда дело доходит до руководителей базовых подсистем ядра, я целиком им доверяю, ведь уже проработал с ними 5, 10, 15 лет, и поэтому даже не смотрю в код. Они описывают мне изменения, делают довольно высокоуровневый обзор. В зависимости от человека, этот обзор может уместиться в пять строк текста с точным описанием изменений, после чего мне предоставляется разница между файлами до и после патча, который меняет, скажем, 15 строк в одном файле и 25 в другом, и даже если в списке различий более ста строк, обычно они разбросаны по очень малому количеству файлов. Я не смотрю сам код, я просто говорю, ОК, изменения вносятся в эти файлы, я доверяю тебе их изменение и все хорошо. А они просто отвечают: я справляюсь.
 
Glyn Moody: Так какова же ваша роль сейчас?
 
Linus Torvalds: Я главным образом управляю людьми. Не в капиталистическом смысле - я никому из них не плачу денег, да и не моей заботой являются их проблемы с оборудованием и подобные вопросы. В общем, я принимаю участие в возникающих в коллективе спорах, особенно если люди конфликтуют, или когда в ядре обнаруживаются ошибки.
 
Ошибки появляются всегда, но довольно часто мы даже не знаем, кто именно прислал нам сообщение об ошибке. Люди просто присылают багрепорты в список рассылки Linux Kernel, а ведь на самом деле ни у кого не хватит сил прочитать его весь. Так, если после записи в списке рассылки ничего не происходит, то они начинают бомбардировать запросами лично меня: эй, мой компьютер не работает. А так как даже не принимаюсь за чтение кода, но знаю, кто отвечает за данный вопрос, то моим делом становится наладить взаимосвязь между сообщением об ошибке и актуальным требованием к действию. Вот и все, и чем я занимаюсь изо дня в день - это чтение электронной почты. И это неплохо, мне нравится, но это уж очень сильно отличается от того, чем я занимался раньше.
 
Glyn Moody: Не означает ли это, что есть необходимость написать еще один инструмент наподобие Git, но не для управления кодом, а для управления людьми?
 
Linus Torvalds: Не думаю, что мы будем этим заниматься. Такие инструменты уже должны существовать, но на самом деле, большая часть моих дел так или иначе завязаны на человеческих взаимоотношениях. У нас есть инструменты, показывающие, кто за что отвечает и кто виноват. У нас есть инструменты, чтобы сказать: да, мы знаем, что в этом участке кода есть проблема, что известен тот, кто редактировал его последним, и тот, кто отвечает за работу этой подсистемы - ведь над нашим проектом работает так много человек, что без каких-то средств автоматизации отследить их действия просто невозможно. Но в то же время, большая часть времени уходит на взаимодействие, а разные люди взаимодействуют друг с другом по-разному, и чрезмерное использование автоматизации для кого-то из них может быть крайне неприятным.
 
Но у нас все получается неплохо. Те проблемные случаи, возникающие у нас лет десять назад, уже не повторятся. И это потому, что мы привыкли к плоской структуре, что мы улучшили свои инструменты и рабочие течения. И это относится не только ко мне, а ко всем разработчикам ядра; у нас нет ни единого человека, кто отклонялся бы от этого курса.
 
Ко мне поступает много электронной почты, но я не могу сказать, что я устал от нее. Например, я очень люблю читать письма в путешествиях со своего телефона. Я читаю их даже во время перерывов, ведь 90% их требуют простого ознакомления. Мне не нужно ничего предпринимать. Мне также сообщат, если в ядре что-то идет не так, я должен быть в курсе, но мне ничего не придется делать самому. Поэтому я могу выполнять 90% своей работы даже в путешествиях, даже без компьютера. И уже вечером, когда я возвращаюсь в номер отеля, то начинаю заниматься оставшимися 10%.
 
Glyn Moody: 16 лет назад вы сказали, что вашей движущей силой являются запросы из внешнего мира; мы все замечаем огромный интерес к мобильным технологиям и планшетам, каково их влияние на разработку ядра?
 
Linus Torvalds: В мире планшетов самая важная вещь - это энергопотребление, в основном потому, что они больше, чем телефоны. У них более емкие батареи, но с другой стороны люди ждут от них дольшего времени жизни от зарядки. У них большие дисплеи - а это снова означает большее энергопотребление. Поэтому в смысле разработки ядра, планшет, с точки зрения его устройства и использования, - тот же самый телефон, а значит, мы знаем, как нам быть в этом случае, главным образом благодаря Android.
 
Интерфейс пользователя у планшета всегда имел болезненные симптомы, и это хватило, чтобы вовсе удалить его из ядра. На телефоне браузер не является полноценным, все привыкли к простым мобильным браузерам. На планшетах все ожидают увидеть полноценный браузер, в котором вы можете кликать по маленьким ссылочкам. Это все означает, что главные проблемы планшетов находятся на пользовательском уровне. Мы решили множество проблем, вызванных все-таки функциональным преимуществом планшетов над телефонами, но могу сказать твердо, что поддержку планшетов мы получили даром.
 
Glyn Moody: А что насчет облачных вычислений, как их рост повлиял на ядро?
 
Linus Torvalds: Наибольшее влияние проявилось в том плане, что даже на серверной стороне, когда дело касается облачных вычислений, люди становятся очень требовательными к энергоресурсам. Мы привыкли, что вся работа над энергопотреблением велась в сфере телефонов, и только в последние три-четыре года сюда вклинились сервера. Это потому, что теперь большие их количества работают вместе, тогда потребление энергии достигает пика. Если вы посмотрите, например, на  Amazon, их пиковые нагрузки на порядки больше, чем нагрузки во время простоя. Даже просто торговая площадка Amazon в конце ноября, декабря, за месяц до Рождества, выполняет столько вычислений, сколько не выполняет за все остальное время. Суть в том, что они должны масштабировать свою аппаратную инфраструктуру для того, чтобы выдержать этот пик в конце года силой лишь одной десятой их мощности. Поэтому возможность отключения питания крайне важна, она сберегает громадные суммы денег провайдерам больших серверных площадок.
 
Glyn Moody: А разработчики из Amazon тоже вовлечены в работу над ядром?
 
Linus Torvalds: Amazon  - не самый яркий пример, Google, вероятно, лучше, так как на них работают очень многие разработчики ядра. В основном, все, что им нужно, они могут сделать сами специально для Google. Мне кажется, что Amazon использует более стандартные компоненты. Хотя, и они изменили подход к построению своих аппаратных решений – для этого у них есть собственные разработки. Раньше они покупали оборудование у HP и Dell, но это закончилось тем, что когда ты покупаешь по 10,000 компьютеров, то в какой-то момент задумываешься, что проще разработать их самому, и ты идешь прямо у производителям оборудования и говоришь: я хочу вот такую машину. Только Amazon начал так делать совсем недавно.
 
Не знаю, насколько в стороне от IT-прогресса находится Amazon, или насколько Google более ориентирован на технологии. Amazon больше работал на пользовательском уровне и использовал стандартное ядро. Google больше работал на стороне ядра, у них даже есть собственные файловые системы. У них используются собственные драйверы для жестких дисков, поскольку в Google совсем нестандартные требования к ним.
 
Glyn Moody: Насколько полезной для вас оказалась работа Google над компонентами ядра?
 
Linus Torvalds: В течение нескольких лет - это было лет пять-десят назад - Google был просто черной дырой. Они нанимали к себе разработчиков ядра, и те просто исчезали с лица земли. Они работали внутри Google,и никто после этого ничего не слышал о их судьбе, потому что они разрабатывали проекты специально для Google, а Google не так охотно делится своими новостями.
 
Но затем ситуация кардинально поменялась, вероятно, потому что Google долгое время жил на ядре версии 2.4. Они использовали эти ядра в течение многих лет, так как потратили на их модификацию и специализированное оборудование много сил и времени. Поэтому обновление ядра было для них серьезной проблемой. И частично даже из-за всего проекта Android, который они мечтали полностью держать в собственных руках.
 
А сейчас они более активны, люди перестали исчезать. Да и ядро стало лучше, многие проблемы оказываются лишь мелкими деталями, а не глубокими ямами. Google решил просто использовать стандартное ядро, плюс некоторые свои модификации поверх него, вместо того, чтобы кромсать все направо и налево, они заново продумали свои инфраструктуру.
 
Glyn Moody: В завершение, вы говорили, что проводите много времени за чтением почты. Не беспокоит ли вас этот факт, ведь когда-то вы считались воплощением истинного хакера?
 
Linus Torvalds: Я бы не сказал, что это меня беспокоит. Да, сейчас я пишу меньше кода, чем мне хотелось бы. С другой стороны, это такие виды программирования, которыми мне не хочется заниматься. Когда мне было двадцать лет, мне нравилось писать драйвера. Если мне никогда не придется писать ни единого драйвера, моя жизнь будет прожита счастливо. Я легко обойдусь без этой разновидности головной боли.
 
Мне очень нравилось работать над Git, это было весело. Когда я начал разработку архитектуры, обозначив свои рамки уровнем пользователя, мне казалось - ой, как все просто, ведь я не делал этого уже лет 15. Мне не пришлось даже задумываться обо всех глубинных вещах - у меня бесконечный стек, malloc работает как надо. Но в пространстве ядра нам нужно позаботиться о возникающих блокировках, о безопасности, об оборудовании. Работа над Git была таким облегчением. Но потом она начала казаться скучной.
 
С другой стороны, я все еще вовлечен в разработку декомпрессиометров. У нас обнаружилась уязвимость на сайте kernel.org. Это причинило много забот разработчикам и администраторам сайта, мы даже задействовали ФБР, чтобы разобраться, что такое произошло. Работа над ядром прервалась почти на два месяца - конечно, люди работали у себя дома, но главный сайт, где все они имели возможность собираться вместе, лежал. Многие мои коллеги провели долгие часы, выясняя, не пробрались ли злоумышленники на и их собственные компьютеры. Мы стали более параноидальными.
 
Поэтому на пару месяцев была прервана и моя основная работа по интеграции результатов работы других людей в проекта, все из-за обрушения сайта. Мне стало скучно, и я занялся веселый делом разработки декомпрессионного компьютера. То есть в итоге я все равно возвращаюсь к программированию ядра, даже несмотря на то, что и не занимаюсь этим по роду службы.