БСД: Большие и Страшные Демоны
Продолжим нашу серию статей, посвященную знакомству с ЮНИКС-подобным семейством BSD. Сегодня мы рассмотрим как модель разработки BSD, так и вообще проблемы развития сообщества открытых исходников. Сделать это будет и проще и нагляднее, если провести сравнение на конкретных примерах, например, FreeBSD и Linux, как наиболее известных и популярных в широких народных массах проектах ОС.
Сегодня тема разработки программ с открытыми исходниками стала очень модной и сверхпопулярной, она не сходит с новостных лент и страниц газет, а для какого-то слоя представителей IT, часто называемого гиками, эта альтернативная модель разработки и ее идеология превратились в непогрешимую религию и образ мышления. В этих новостях часто акцентируются достижения и всяческие преимущества этой модели разработки, но, что стало уже обычным, при этом замалчиваются все трудности, неудачи и даже провалы в мире открытых исходников. По всем признакам мы переживаем стадию становления нового культа с ярко выраженным мессианским контекстом для открытого софта. Благодаря такому плотному информационному давлению у многих остается впечатление, что открытые исходные тексты - суть панацея, единственно верное решение, которое решит все, или почти все трудности, и уже совсем скоро чуть ли не завоюет весь мир программного обеспечения. При этом часто используется прием противопоставления, когда тот же Linux позитивно противопоставляется тому же негативному Windows, хотя, как я уже отмечал в прошлой своей статье, по своему внутреннему дизайну Linux сейчас все больше и больше приближается к дизайну и концепциям именно Windows, что отмечают специалисты по архитектуре ОС.
Прежде всего, давайте остановимся на специфике так называемой базарной модели разработки (bazaar model) и вкратце обозначим ее основные закономерности, на которых базируется разработка open source проектов. Вот что пишет апологет BSD Джордан Хаббард: "Внимательный анализ причин успехов анархической ("базарной") модели разработки программ зачастую выявляет существование значительной степени централизации, которая на самом деле является неотъемлемой чертой процесса разработки таких программ." Вслед за авторитетом подтвердим уже установленный факт, что в любом случае любой устойчиво развивающийся проект с открытыми исходниками приходит в процессе своего развития к высокому уровню централизации. Эта потребность в централизации может восприниматься участниками как "культ личности", когда один из разработчиков имеет огромную власть (например, как Линус Торвальдс в Linux). Это, в свою очередь, может привести к высокому уровню внутренних трений и разногласий. Итак, соглашаясь с тем, что централизация неизбежна, все же намечаются первые отличия в ее реализации в различных открытых проектах, например, рассмотрим это на примере наших FreeBSD и Linux. В FreeBSD-мире существует т.н. Core Team, которая демократически выбирается разработчиками (коммитерами) раз в 2 года путем открытого голосования, куда в результате выборов входит 9 самых авторитетных и активных коммитеров данной ОС – к этой группе переходит вся полнота власти по управлению и модерированию проектом на указанный период времени. В Linux же мы имеем жесткую централизацию и культ личности одного человека. В самом деле, в последнее время в сообществе Linux очень активно обсуждается проблема с излишней зависимостью всего проекта лишь от одного человека: “Не настало ли время для Линуса Торвальдса разделить бремя ответственности, лежащее на нем, с кем-нибудь еще?”
Модель разработки ядра Linux такова, что право публиковать код в "официальный" репозиторий имеет только один человек во всем этом гигантском проекте. Конечно, множество майнтейнеров присматривает за разными подсистемами ядра, но каждый утвержденный ими патч, если в итоге он должен быть влит в главную ветвь, будет проверен и добавлен туда только лично Линусом. Подобная суперавторитарная модель разработки просто немыслима для мира FreeBSD, где судьба всех глобальных и спорных “коммитов” как в HEAD, так и в STABLE, в любом случае обсуждаются и решаются коллективно. Вспоминается знаменитый эпизод 1998 года, когда Линус был в сильной депрессии и раздражении, и вообще “забил” на разработку своей ОС, далеко посылая всех, кто высылал ему любой патч (удаляя их вообще), что привело к ропоту и большим народным волнениям в рассылках линуксоидных разработчиков (“говорят, Царь-то с ума сошел!”). В связи с этим сейчас активно обсуждается так называемый "фактор автобуса" (bus factor), вошедший в обиход из известного шутливого исследования “Что будет с Linux, если Линуса Торвальдса собъет автобус” (можно найти много пародийных этому оригиналу псевдоисследований, например, “Что будет, если всех участников FreeBSD Core Team собьют автобусы”, или “Что будет, если в автобус, в котором едут Стив Джобс, Билл Гейтс, Ларри Элисон и Линус Торвальдс, угодит другой автобус?”). Как минимум высказываются мнения, что Линус должен начинать готовить себе преемников, как максимум – что подобный гигантский централизованный проект не должен быть замкнут на одном единственном человеке. Уже сейчас процесс коммита в главную ветвь Linux занимает очень продолжительное время – Линукс буквально завален уже утвержденными мантэйнерами патчами. Как высказывается ведущий разработчик из Red Hat: “У Linux чрезвычайно распределенная и гибкая модель разработки, с единственным узким местом в ней – самим Линусом”. Другой разработчик из IBM добавляет: “Возьмите сверхсложную систему, сложность которой шокирующе нарастает, добавьте туда жесткую централизацию в ее управлении, и вы увидите, что в динамике такое развитие объективно приводит к "культу личности" в худших традициях социализма. Хотя изначально исходило все как всегда, конечно же, из самых лучших побуждений”.
Другая острейшая проблема Linux – это падение качества кода и чудовищный темп увеличения размеров ядра. Ранее, в 80-х, классический подход разработки ПО, который, кстати, удачно сформулировал сам Линус Торвальдс, утверждал, что "при достаточном количестве глаз все ошибки лежат на поверхности" (Given enough eyeballs, all bugs are shallow), поэтому всем большим коллективам разработчиков, несомненно, приписывались преимущества в разработке. Но глядя на современный мир, с его гигантскими сообществами разработчиков, например, как у Linux, методология разработки вынужденно формулирует т.н. закон Брукса: время программистов не аддитивно; увеличение числа разработчиков проекта, который, например, отстал от графика, ведет к еще большему его запаздыванию. Этот закон утверждает, что сложность и затраты на общение и согласование в проекте возрастают пропорционально квадрату числа разработчиков, в то время как полезная работа возрастает только линейно. Это утверждение сейчас стало широко известным и проверенным на опыте, и уже часто рассматривается как очевидный факт. Поэтому бесконтрольное разрастание огромного и разнородного сообщества разработчиков Linux на самом деле приводит к тому, к чему оно и приводит – как минимум к сильнейшей фрагментации и распылению проекта (практически все крупные дистрибутивы используют огромное количество своих собственных патчей к официальному ядру), как максимум - к падению качества дизайна ядра (о чем мы говорили в прошлой статье, и будем говорить более предметно в следующих статьях из этой серии). В FreeBSD, как уже отмечалось выше, имеется иерархическая система принятия изменений в ядро, которая будучи распределенной прекрасно справляется и переваривает нагрузку с постоянно поступающими нововведениями. Кроме того, в FreeBSD существует традиция, что каждый коммитер, ответственный за какую-либо подсистему ядра, формирует вокруг себя своих преемников, которым постепенно, по мере их контролированного прогресса и обучения, вручается права на коммит (commit bit) в дерево исходного кода. Таким образом, в FreeBSD существует негласная школа, которая последовательно передает опыт от одного другому поколению разработчиков, постепенно фильтруя из всех желающих наиболее способных и заранее готовя себе замену, что отчасти противостоит негативным последствиям закона Брукса, сдерживая некачественное разрастание основания в пирамиде модели разработки системы.
Другая острая проблема открытых исходников – это т.н. проблема "самого низко висящего яблока". Дело в том, что, как и в реальной жизни, существуют как престижные и интересные большинству общества виды деятельности (работы), наконец, просто самые легкие и простые, так и не популярные в народе виды деятельности. Проблема "самого низко висящего яблока" приводит к тому, что подавляющее большинство разработчиков в качестве приложения своих сил и умений в проекте выбирает самые простые, интересные или важные подсистемы ядра, тогда как интересы сообщества требуют равномерного развития всей совокупности систем и подсистем, которые входят в ядро в целом. Поскольку труд этот добровольный и ничем другим, кроме собственных желаний и амбиций (а не общей целесообразностью) не мотивируется, то возникает довольно интересный набор проблем, которые можно наблюдать и в нашей реальной общественной жизни. Отчасти поэтому представление о бесплатно работающих и бескорыстных программистах, день и ночь корпящих над ядром Linux, уже давно не более чем миф. В наше время такую корректирующую мотивацию сообществу принято гуманно навязывать через денежные знаки, тогда как еще пару веков тому назад обошлись бы куда проще – создав где-нибудь в дальней Сибири лагерь “Открытых системъ” с Л.Торвальдсом во главе.
В то время бегство из этого лагеря, например, таких ярких ведущих разработчиков ядра Linux, как Алан Кокс и Кон Коливас (как это случилось в наше время), - скорее всего, закончилось бы погоней и предсказуемой судьбой всех не согласных с политикой партии, “которых вздернули бы поутру на главных городских воротах”. Итак, реальные увлеченные добровольцы уходят сегодня из Linux, статистика неумолимо констатирует это: сегодня более чем 90% всех значимых разработчиков ядра Linux работают за зарплату и на конкретные крупные коммерческие компании, которые таким образом вносят свой вклад в развитие ядра, и которые при этом транслируют именно свои коммерческие цели и задачи в развитие этого открытого проекта. Двухполюсность этой модели разработки в целом, когда с одной стороны царь Линус координирует развитие свободной, бесплатной и открытой ОС, а с другой — приоритетами разработки реально рулят коммерческие компании, платящие своим разработчикам деньги, - уж очень потенциально конфликтна и противоречива. Это опять же сильно бросается в глаза в сравнении с моделью той же FreeBSD, где от любой коммерциализации проекта и прихода “больших денег” шугаются как от огня, вполне справедливо понимая последствия такого поступка. На самом деле, очень мало из масштабных разработок в FreeBSD сторонних коммерческих компаний (того же Yahoo или наших Yandex’a и Rambler’a, на ядре FreeBSD в которых работали их поисковые серверы) реально попало в официальную ветвь FreeBSD – только то, что было коллективно одобрено сообществом и укладывалось в последовательную и непротиворечивую концепцию развития ядра. Да, серверы под управлением FreeBSD традиционно удерживают все рекорды по uptime своей работы под реальной нагрузкой, но нужно понимать, что это результат именно жесточайшей дисциплины разработки и непреклонной независимости в своем развитии, где стараются на передний план выдвигать не коммерческую целесообразность и пиар для привлечения новых денег, как это все больше прослеживается в мире Linux, но техническое качество и идейную чистоту реализации дизайна ОС.
В следующей серии статей мы рассмотрим, опять же в сравнении, специфику и проблемы в архитектурах Linux и FreeBSD. Также внимательно изучим стратегию и политику развития т.н. userland – легион дистрибутивов в Linux, и целостность и монолитность этой среды в BSD-проектах. До будущих встреч в мире Больших и Страшных Демонов!
Игорь САВЧУК blogerator.ru
Сегодня тема разработки программ с открытыми исходниками стала очень модной и сверхпопулярной, она не сходит с новостных лент и страниц газет, а для какого-то слоя представителей IT, часто называемого гиками, эта альтернативная модель разработки и ее идеология превратились в непогрешимую религию и образ мышления. В этих новостях часто акцентируются достижения и всяческие преимущества этой модели разработки, но, что стало уже обычным, при этом замалчиваются все трудности, неудачи и даже провалы в мире открытых исходников. По всем признакам мы переживаем стадию становления нового культа с ярко выраженным мессианским контекстом для открытого софта. Благодаря такому плотному информационному давлению у многих остается впечатление, что открытые исходные тексты - суть панацея, единственно верное решение, которое решит все, или почти все трудности, и уже совсем скоро чуть ли не завоюет весь мир программного обеспечения. При этом часто используется прием противопоставления, когда тот же Linux позитивно противопоставляется тому же негативному Windows, хотя, как я уже отмечал в прошлой своей статье, по своему внутреннему дизайну Linux сейчас все больше и больше приближается к дизайну и концепциям именно Windows, что отмечают специалисты по архитектуре ОС.
Прежде всего, давайте остановимся на специфике так называемой базарной модели разработки (bazaar model) и вкратце обозначим ее основные закономерности, на которых базируется разработка open source проектов. Вот что пишет апологет BSD Джордан Хаббард: "Внимательный анализ причин успехов анархической ("базарной") модели разработки программ зачастую выявляет существование значительной степени централизации, которая на самом деле является неотъемлемой чертой процесса разработки таких программ." Вслед за авторитетом подтвердим уже установленный факт, что в любом случае любой устойчиво развивающийся проект с открытыми исходниками приходит в процессе своего развития к высокому уровню централизации. Эта потребность в централизации может восприниматься участниками как "культ личности", когда один из разработчиков имеет огромную власть (например, как Линус Торвальдс в Linux). Это, в свою очередь, может привести к высокому уровню внутренних трений и разногласий. Итак, соглашаясь с тем, что централизация неизбежна, все же намечаются первые отличия в ее реализации в различных открытых проектах, например, рассмотрим это на примере наших FreeBSD и Linux. В FreeBSD-мире существует т.н. Core Team, которая демократически выбирается разработчиками (коммитерами) раз в 2 года путем открытого голосования, куда в результате выборов входит 9 самых авторитетных и активных коммитеров данной ОС – к этой группе переходит вся полнота власти по управлению и модерированию проектом на указанный период времени. В Linux же мы имеем жесткую централизацию и культ личности одного человека. В самом деле, в последнее время в сообществе Linux очень активно обсуждается проблема с излишней зависимостью всего проекта лишь от одного человека: “Не настало ли время для Линуса Торвальдса разделить бремя ответственности, лежащее на нем, с кем-нибудь еще?”
Модель разработки ядра Linux такова, что право публиковать код в "официальный" репозиторий имеет только один человек во всем этом гигантском проекте. Конечно, множество майнтейнеров присматривает за разными подсистемами ядра, но каждый утвержденный ими патч, если в итоге он должен быть влит в главную ветвь, будет проверен и добавлен туда только лично Линусом. Подобная суперавторитарная модель разработки просто немыслима для мира FreeBSD, где судьба всех глобальных и спорных “коммитов” как в HEAD, так и в STABLE, в любом случае обсуждаются и решаются коллективно. Вспоминается знаменитый эпизод 1998 года, когда Линус был в сильной депрессии и раздражении, и вообще “забил” на разработку своей ОС, далеко посылая всех, кто высылал ему любой патч (удаляя их вообще), что привело к ропоту и большим народным волнениям в рассылках линуксоидных разработчиков (“говорят, Царь-то с ума сошел!”). В связи с этим сейчас активно обсуждается так называемый "фактор автобуса" (bus factor), вошедший в обиход из известного шутливого исследования “Что будет с Linux, если Линуса Торвальдса собъет автобус” (можно найти много пародийных этому оригиналу псевдоисследований, например, “Что будет, если всех участников FreeBSD Core Team собьют автобусы”, или “Что будет, если в автобус, в котором едут Стив Джобс, Билл Гейтс, Ларри Элисон и Линус Торвальдс, угодит другой автобус?”). Как минимум высказываются мнения, что Линус должен начинать готовить себе преемников, как максимум – что подобный гигантский централизованный проект не должен быть замкнут на одном единственном человеке. Уже сейчас процесс коммита в главную ветвь Linux занимает очень продолжительное время – Линукс буквально завален уже утвержденными мантэйнерами патчами. Как высказывается ведущий разработчик из Red Hat: “У Linux чрезвычайно распределенная и гибкая модель разработки, с единственным узким местом в ней – самим Линусом”. Другой разработчик из IBM добавляет: “Возьмите сверхсложную систему, сложность которой шокирующе нарастает, добавьте туда жесткую централизацию в ее управлении, и вы увидите, что в динамике такое развитие объективно приводит к "культу личности" в худших традициях социализма. Хотя изначально исходило все как всегда, конечно же, из самых лучших побуждений”.
Другая острейшая проблема Linux – это падение качества кода и чудовищный темп увеличения размеров ядра. Ранее, в 80-х, классический подход разработки ПО, который, кстати, удачно сформулировал сам Линус Торвальдс, утверждал, что "при достаточном количестве глаз все ошибки лежат на поверхности" (Given enough eyeballs, all bugs are shallow), поэтому всем большим коллективам разработчиков, несомненно, приписывались преимущества в разработке. Но глядя на современный мир, с его гигантскими сообществами разработчиков, например, как у Linux, методология разработки вынужденно формулирует т.н. закон Брукса: время программистов не аддитивно; увеличение числа разработчиков проекта, который, например, отстал от графика, ведет к еще большему его запаздыванию. Этот закон утверждает, что сложность и затраты на общение и согласование в проекте возрастают пропорционально квадрату числа разработчиков, в то время как полезная работа возрастает только линейно. Это утверждение сейчас стало широко известным и проверенным на опыте, и уже часто рассматривается как очевидный факт. Поэтому бесконтрольное разрастание огромного и разнородного сообщества разработчиков Linux на самом деле приводит к тому, к чему оно и приводит – как минимум к сильнейшей фрагментации и распылению проекта (практически все крупные дистрибутивы используют огромное количество своих собственных патчей к официальному ядру), как максимум - к падению качества дизайна ядра (о чем мы говорили в прошлой статье, и будем говорить более предметно в следующих статьях из этой серии). В FreeBSD, как уже отмечалось выше, имеется иерархическая система принятия изменений в ядро, которая будучи распределенной прекрасно справляется и переваривает нагрузку с постоянно поступающими нововведениями. Кроме того, в FreeBSD существует традиция, что каждый коммитер, ответственный за какую-либо подсистему ядра, формирует вокруг себя своих преемников, которым постепенно, по мере их контролированного прогресса и обучения, вручается права на коммит (commit bit) в дерево исходного кода. Таким образом, в FreeBSD существует негласная школа, которая последовательно передает опыт от одного другому поколению разработчиков, постепенно фильтруя из всех желающих наиболее способных и заранее готовя себе замену, что отчасти противостоит негативным последствиям закона Брукса, сдерживая некачественное разрастание основания в пирамиде модели разработки системы.
Другая острая проблема открытых исходников – это т.н. проблема "самого низко висящего яблока". Дело в том, что, как и в реальной жизни, существуют как престижные и интересные большинству общества виды деятельности (работы), наконец, просто самые легкие и простые, так и не популярные в народе виды деятельности. Проблема "самого низко висящего яблока" приводит к тому, что подавляющее большинство разработчиков в качестве приложения своих сил и умений в проекте выбирает самые простые, интересные или важные подсистемы ядра, тогда как интересы сообщества требуют равномерного развития всей совокупности систем и подсистем, которые входят в ядро в целом. Поскольку труд этот добровольный и ничем другим, кроме собственных желаний и амбиций (а не общей целесообразностью) не мотивируется, то возникает довольно интересный набор проблем, которые можно наблюдать и в нашей реальной общественной жизни. Отчасти поэтому представление о бесплатно работающих и бескорыстных программистах, день и ночь корпящих над ядром Linux, уже давно не более чем миф. В наше время такую корректирующую мотивацию сообществу принято гуманно навязывать через денежные знаки, тогда как еще пару веков тому назад обошлись бы куда проще – создав где-нибудь в дальней Сибири лагерь “Открытых системъ” с Л.Торвальдсом во главе.
В то время бегство из этого лагеря, например, таких ярких ведущих разработчиков ядра Linux, как Алан Кокс и Кон Коливас (как это случилось в наше время), - скорее всего, закончилось бы погоней и предсказуемой судьбой всех не согласных с политикой партии, “которых вздернули бы поутру на главных городских воротах”. Итак, реальные увлеченные добровольцы уходят сегодня из Linux, статистика неумолимо констатирует это: сегодня более чем 90% всех значимых разработчиков ядра Linux работают за зарплату и на конкретные крупные коммерческие компании, которые таким образом вносят свой вклад в развитие ядра, и которые при этом транслируют именно свои коммерческие цели и задачи в развитие этого открытого проекта. Двухполюсность этой модели разработки в целом, когда с одной стороны царь Линус координирует развитие свободной, бесплатной и открытой ОС, а с другой — приоритетами разработки реально рулят коммерческие компании, платящие своим разработчикам деньги, - уж очень потенциально конфликтна и противоречива. Это опять же сильно бросается в глаза в сравнении с моделью той же FreeBSD, где от любой коммерциализации проекта и прихода “больших денег” шугаются как от огня, вполне справедливо понимая последствия такого поступка. На самом деле, очень мало из масштабных разработок в FreeBSD сторонних коммерческих компаний (того же Yahoo или наших Yandex’a и Rambler’a, на ядре FreeBSD в которых работали их поисковые серверы) реально попало в официальную ветвь FreeBSD – только то, что было коллективно одобрено сообществом и укладывалось в последовательную и непротиворечивую концепцию развития ядра. Да, серверы под управлением FreeBSD традиционно удерживают все рекорды по uptime своей работы под реальной нагрузкой, но нужно понимать, что это результат именно жесточайшей дисциплины разработки и непреклонной независимости в своем развитии, где стараются на передний план выдвигать не коммерческую целесообразность и пиар для привлечения новых денег, как это все больше прослеживается в мире Linux, но техническое качество и идейную чистоту реализации дизайна ОС.
В следующей серии статей мы рассмотрим, опять же в сравнении, специфику и проблемы в архитектурах Linux и FreeBSD. Также внимательно изучим стратегию и политику развития т.н. userland – легион дистрибутивов в Linux, и целостность и монолитность этой среды в BSD-проектах. До будущих встреч в мире Больших и Страшных Демонов!
Игорь САВЧУК blogerator.ru
Компьютерная газета. Статья была опубликована в номере 35 за 2010 год в рубрике ос
