Читаем Журнал "Компьютерра" N734 полностью

Журнал "Компьютерра" N734

Сами правила обычно носят традиционный характер (устоявшиеся со временем принципы) или являются высказываниями Линуса, против которых нет серьезных возражений. "Линус говорит, что есть еще такая вещь, как хороший вкус, - но его, увы, трудно кодифицировать", - добавляет Мортон.

Помимо вкуса, важными могут оказаться еще и хорошие манеры. Долгое время список рассылки LKML не считался особо приветливым и дружелюбным местом, особенно для новичков - разработчики ядра в технических дискуссиях порой выражаются довольно крепко. Впрочем, ситуация меняется.

- Да, участники LKML иногда бывают грубыми, но обычно это допустимо только между людьми, которые хорошо знают друг друга. Если появляется кто-то, о ком мы никогда не слышали, скажем, с сообщением об ошибке или патчем, мы проявляем к нему большое уважение. У нас действительно была репутация людей, недружелюбно относящихся к новичкам, но ситуация изменилась примерно пять лет назад. Это открыто обсуждалось на Kernel Summit - мы тогда поняли, что наша репутация отталкивает от нас людей и вредит процессу разработки - и решили изменить манеру поведения. Принятое тогда решение приносит плоды: например, у нас существенно выросло количество новых участников из Азии - в частности, из Японии, где вежливость возведена в культ.

Почтовый список LKML - основное средство взаимодействия между разработчиками.

- Мы используем IRC-чаты, но в основном как раз для того, чтобы нагрубить друг другу, - улыбается Мортон. - Я также не люблю частные письма - считаю, что технические дискуссии должны вестись в публичном списке, архив которого доступен для поиска. Всякий раз, когда мне пишут частное письмо по поводу технических вопросов, я теряюсь - например, нужно ли вовлекать в дискуссию других людей. Я подписан более чем на шестьдесят списков рассылки, но никогда их не читаю. Зато когда я вижу патч, то могу посмотреть архив списка на моем компьютере, прочитать комментарии и т. д.

Список рассылки вообще кажется Мортону самым удачным способом обсуждения технических вопросов.

- Даже если бы все разработчики ядра сидели в одном большом здании, способ разработки вряд ли сильно бы изменился. Когда мы встречаемся на конференциях с разработчиками Linux, я не очень люблю говорить о технических аспектах. Если такие разговоры начинаются, уже на тридцатой секунде я говорю: "слишком много информации, давайте по почте". Почта позволяет вести очень сложные технические дискуссии.

С Линусом и другими разработчиками ядра Мортона связывают в основном деловые отношения. "Да, еще мы выпивали вместе на различных мероприятиях", - смеется он.

Вид на будущее

Революций в ядре, аналогичных переходу с 2.4 на 2.6, больше не планируется - в обозримой перспективе две первые цифры версии меняться не будут вовсе. Основная причина: качество кода сейчас достаточно высокое, и никакие компоненты не нужно переписывать с нуля - а можно постепенно дорабатывать и улучшать то, что есть, вводя новые функции и исправляя старые баги.

Говоря о будущем свободного и открытого ПО, Мортон отмечает, что сейчас во многих областях нет причин создавать конкурирующие решения, реализующие один и тот же набор функций - лучше вкладывать ресурсы в доминирующую открытую реализацию. О возможных угрозах со стороны "темных сил мира" Мортон тоже не слишком беспокоится.

- Теоретически возможна атака с использованием софтверных патентов - но я не вижу никаких признаков того, что кто-то намерен это сделать. Это будет атака против собственных клиентов. Мне кажется, что open source находится в безопасности - просто потому, что люди хотят пользоваться открытым софтом.

Зачем делиться кодом

В своем докладе на Open Source Forum @ Interop Мортон рассказал, как компании используют ядро Linux и включаются в процесс разработки. Дело в том, что ядро зачастую приходится адаптировать для каких-то специфических внутренних применений - и очень часто компании не планируют внедрять эти изменения в основную ветвь. В результате им приходится адаптировать свою модификацию по мере выхода новых версий официального ядра - и чем дальше, тем этот процесс требует все больше ресурсов. Гораздо правильнее с самого начала планировать интеграцию внутренних модификаций с основной веткой - это позволит не только сэкономить на дальнейшей поддержке кода и исправлении ошибок, но и улучшит репутацию компании в сообществе разработчиков.