Кому интересно, посмотрите
На днях прочитал интервью Яна Мердока, автора проекта Debian, и почерпнул для себя очень много нового и интересного.
Интервью "Ian Murdock: Debian "missing a big opportunity"" было напечатано в мартовском номере журнала LINUX FORMAT и перепечатано в майском номере русскоязычной версии журнала.
Интервью напрямую относится к нашей дискуссии об отечественной операционной системе и те проблемы, которые предстоит решать при разработке такой ОС, наглядно высвечены в интервью Яна Мердока.

Ян Мердок [Ian Murdock] впервые затронул Linux, когда разработал манифест Debian и создал дистрибутив Linux, известный как Debian, в 1993. На этом он не остановился, и в 1999 году основал Progeny, ИТ-компанию на рынке Linux. Сейчас работает главным технологом в новообразованном Фонде Linux (Linux Foundation; появился в результате слияния OSDL и Free Standards Group) [уже нет: пока верстался номер, Мердок перешел на работу в Sun Microsystems, - прим. ред.]; его роль - ни больше ни меньше, как обеспечить надежность и стандарты в ОС Linux OS. Ник Вейч встретился с Яном в Нью-Йорке и обрушил на него вопросы читателей Linux Format, страдающих Debian-фобией.

Linux Format: Вы довольны тем, во что превратился Debian?
Ян Мердок: В общем-то, вполне доволен. Ясно, что Debian совершил немало хорошего и оказал мощное влияние. Он решительно превзошел все мои ожидания. Но есть аспекты, несколько обескураживающие меня.
По-моему, в некоторых отношениях Debian упустил большую возможность. Если рассмотреть, как используется Linux, от крупных предприятий до другого края спектра, то Debian - один из трех крупных дистрибутивов во всем мире: два других - Red Hat и SUSE. И есть несколько мелочей, которые его тормозят. А большой недостаток - то, что у него никогда не было предсказуемого графика релизов. Когда выйдет следующая версия? «По мере готовности» - это не самый притягательный ответ для широкого рынка, верно?
Полтора года назад я сказал, что перед Debian открываются широкие возможности, и что важнее всего для этого вовремя выпустить Etch. И вот мы видим не только провал, но и образ действий, который к нему привел - а именно, кое-какие разработчики предсказывали, что все это работать не будет, потому что деньги вложены в формулу проекта Dunc-Tank [группа оплачиваемых разработчиков дистрибутива Debian, - прим. пер.], обреченного на провал, и сами же пассивно-агрессивно вели себя так, чтобы это предсказание оправдалось, иллюстрируя худшие свойства процесса разработки программ с открытым кодом. Не говоря уже о том, что они [Debian] теряют отличные возможности.

LXF: Непохоже, что в других дистрибутивах столько внутренних раздоров.
ЯМ: В какой-то мере они довольно типичны. Такие раздоры можно наблюдать в любой фирме - вопрос в том, до какой степени они выплескиваются на публику. По большей части вы о них и не подозреваете, потому что все разборки происходят за закрытыми дверями. Так что на самом деле ничего нового тут нет. Просто в Debian все настолько открыто и прозрачно, что все на виду.
Я думаю, что в какой-то мере Debian овладел процессный амок. Должен существовать некий процесс, подлежащий масштабированию. Я хочу сказать, вы начинаете с одного человека, потом доходите до десяти - и перед вами проявляется новый набор проблем. Затем вы переходите от десяти к сотне, от сотни к тысяче, и следует выстраивать процесс в соответствии с его масштабом. Проблема слишком обширного процесса состоит в том, что разработку выполняет комитет - то есть нет сильного лидера, и никто не вправе взять принятие решений на себя. А иногда нужно принимать непопулярные решения; для этого и служат лидеры. В итоге такой комитет приходит к тому, что никто не отваживается принимать решения, пока с этими решениями не согласятся все. Но ведь организация разрастается, и всех удовлетворить получается невозможно, поэтому решения не принимаются вообще. Вот в таком тупике оказался сегодня Debian.

LXF: Если Debian выдохся, что тут исправишь?
ЯМ: Честно говоря, я такое уже вижу на Slashdot ...так что я мог бы продолжать! Я считаю, фундаментальной ошибкой стало принятие этого демократического процесса, которое произошло уже после моего ухода и которому я противился.

LXF: Так вы были против этого?
ЯМ: Да, я был против. В основном причина та же: по-моему, в открытых проектах , как в любом бизнесе, чтобы сделать серьезную работу, нужно сильное руководство. И я думаю, именно это одна из причин успеха Ubuntu: у них есть сильный лидер, причем облеченный властью. Просвещенный руководитель прислушивается к мнению сообщества и принимает его к сведению, и понимает, что ему случается принимать и плохие решения, которые надо будет пересматривать. Полагаю, что ратовавшие за чистую демократию в Debian в какой-то мере рассматривали это как социальный эксперимент- что произойдет, если все решения ставить на голосование. Знаете, демократия в чистом виде... Она намного лучше выглядит на бумаге, чем получается на практике. Поэтому-то я всегда и был против. Знаете, меня порадовало нынешнее руководство Debian: я думаю, Энтони Таунс [Anthony Towns] хорошо поработал, и он не боится принимать непопулярные решения, примером чего может служить Dunc-Tank. С этой точки зрения, это в большей степени проблема организации. Будем надеяться, что сильное руководство будет продолжаться.

LXF: Вы упомянули Ubuntu. Многие относятся к нему, как к «доведенному до ума» Debian. Вас не расстраивает, что Ubuntu - это фактически популистская версия Debian?
ЯМ: Позвольте мне теперь заступиться за Debian, после моих на него нападок. Нельзя забывать, насколько Debian был передовым и инновационным. Вся идея открытой разработки, распределенной разработки... это была модель, впервые примененная именно в Debian. Лавры первопроходца принадлежат Linux, но Deb стал первой попыткой создать что-либо таким способом.
Естественно, что разрушая старые основы и осваивая новое, совершаешь ошибки; успешность организации определяется, среди прочего, способностью осознать совершенную ошибку. Утверждение, что Ubuntu - это правильно сделанный Debian, отчасти подразумевает, что Debian сделан неправильно, а это уже, моему мнению, заблуждение. А может ли Debian чему-то научиться у Ubuntu -исключительной восприимчивости и всему хорошему, что в нем, если честно признать, есть? Разумеется. Я думаю, это единственное положительное влияние Ubuntu.
Ubuntu определенно поднял планку. Он оказал громадное влияние на множество людей во всем мире, которые используют Debian (а я считаю, что Ubuntu - Debian). Полагаю, что ошибки они тоже делали, но они показали свою способность признавать просчеты и исправлять их. Еще раньше я достаточно громко выражал свое мнение по поводу совместимости, а именно: начали появляться пакеты Debian которые в Debian невозможно запустить. Я помню, как это случилось с RPM в конце девяностых, и я не хотел, чтобы подобное произошло с Debian. Мы расходились во мнениях по поводу того, как делать разные вещи - DCC и прочее, возникавшее и исчезавшее. Но в конечном итоге, в настоящее время Ubuntu является активным участником моего текущего проекта, Linux Standard Base (LSB), ядром которого является совместимость, так что мои ранние опасения как раз и приняты внимание.

LXF: Это приводит меня к следующему вопросу: не настанет ли момент, когда Linux Standard Base будет лоббировать какой-то конкретный мененджер пакетов?
ЯМ: Это имеет смысл, если люди просят. Но надо постоянно помнить, как работает LSB: мы действуем в мире, где уже существуют многочисленные реализации. Нельзя просто придти и заявить: «Тот прав, а этот ошибается». Скорее вы усаживаетесь рядом с человеком и говорите: «Мы ведь все согласны с тем, должны в чем-то придти к общему мнению, так почему бы вам не согласиться со мной, и все будет отлично?» А он в это время сидит рядом с вами и думает в точности то же самое...
Что же касается пакетов - да, некий стандарт пакетов определенно необходим. Взгляните на станицу закачки любого приложения Linux - ну, хоть MySQL: вы увидите там 15 разных пакетов. RHEL4 - вepсия, RHEL5-версия, Debian-версия, каких только версий нет; и в какой-то степени LSB создана для того, чтобы решить проблему создания приложений таким образом, чтобы приложение работало в разных дистрибутивах; но она совершенно не касается того, как эта программа фактически появляется в системе. Поэтому мы недавно начали работу над стандартом пакетного менеджмента, и главным будет подход к этой работе. Мы пришли к дистрибутивам, потому что осознали: если мы хотим, чтобы стандарт имел вес во всем мире, дистрибутивы должны не заглатывать его без разбора, а открыто применять, в противном случае...

LXF: В этом нет смысла.
ЯМ: Да! Получится, что мы разработали стандарт, которым никто не пользуется и, значит, зря потратили время. Поэтому мы собираем всех вместе и говорим: «Вот проблема, на которую надо обратить внимание», и по большей части все соглашаются. Обычно на этом месте все и распадается, потому что люди приходят и говорят: «Очевидно, чтобы продвинуться вперед, надо...» Обычно предлагаемое решение подразумевает необходимость все переписать.

LXF: Это решение а-ля Канберра, да? Невозможно выбрать между двумя одинаковое хорошими вещами, и выбирают нечто слегка подмоченное.
ЯМ: Если бы! Выбрать - это еще полбеды, но ведь не выбирают, а создают что новое. Что касается стандартизации LSB, нам приходится работать в сильно распределенном, многополюсном мире, в котором способ создания стандарта так же важен, как его поддержание.

LXF: А нету ли опасности того, что приняв нечто как стандарт, мы утратим стимул к усовершенствованию?
ЯМ: Здесь мы приходим к вопросу взаимоотношений стандартов и инноваций. Обеспечивать стандарты вовсе не означает тормозить инновации, и на самом деле расширить инновацию можно, стандартизируя как можно меньше. Так что применительно к пакетам, не слишком важно, что все устанавливают пакеты в одинаковом формате, не слишком важно и то, чтобы при наличии двух пакетных систем обе обладали одинаковыми способностями и одинаковым интерфейсом. А важно вот что: чего потребителю технологии нужно от этой технологии? В случае с пакетами, об этом следует спрашивать у потребителей - разработчиков программ, которые желают создать единое приложение Linux, способное работать в любом дистрибутиве. Они говорят: «Слушайте, мы уже поддерживаем две, три, четыре разных платформы, и нам неохота поддерживать еще одну - нам не нужно RPM. Мы потому и пишем скрипты оболочки, чтобы просто загружать файлы в файловую систему. И нам годится расширяемое решение, которое позволит нам добавлять несколько маленьких строчек к коду, который у нас есть на сегодняшний день. Не вынуждайте нас вышвыривать все наши наработки в окно только потому, что вам не нравится предыдущая технологическая итерация». На самом деле все очень просто: стандартизировать как можно меньше и не вступать в дискуссию, имея некое предвзятое мнение о конечном результате.

LXF: Каковы, по-вашему, основные проблемы, стоящие перед LSB?
ЯМ: Основной проблемой, стоящей перед LSB, является сама по себе сложность работы, которую нам приходится выполнять. Если подумать о платформе Linux, она вовсе не так уж хорошо сгруппирована. Фактически, существуют десятки, или сотни, или тысячи различных компонентов, поддержкой которых занимаются самые разные люди, с самыми разными приоритетами. Кто-то понимает важность совместимости, кому-то до этого и дела нет - они хотят менять все, что им хочется, и когда им хочется.
Наша работа в том, чтобы упорядочить хаос - или, по крайней мере, скрыть его. Есть люди, которым подавай Linux как единую платформу, а тот факт, что в нем около 100 разных дистрибутивов, и что иногда какой-нибудь мелкий компонент разрушает всю совместимость в силу некой таинственной причины... это заставляет таких людей думать: «А вообще, жизнеспособен ли Linux?»
Проблема, стоящая перед нами - чтобы все эти люди с такими разными интересами стремились к одной цели.

LXR Зачем?
ЯМ: Потому что по мере роста Linux все больше людей сталкиваются со все более болезненными проблемами, которые мы пытаемся решать. Всегда трудно убедить людей начать лечить болезнь, которая еще не началась. «Но болезнь обязательно начнется через несколько лет, доверьтесь нам, мы собираемся предотвратить ее». Людей гораздо проще убедить заняться лечением, но не профилактикой.

LXF: Слияние OSDL с FSG облегчит ситуацию?
ЯМ: Да, определенно. Что касается FSG и OSDL, деятельность этих организаций в значительной степени пересекалась. В уставах этих организаций, на бумаге, никакого пересечения деятельности не было, но на самом деле оно было. Мы занимались LSB, a OSDL занимались Carrier Grade Linux [CGL] и Portland, которые весьма похожи на стандарты. В какой-то мере мы конкурировали друг с другом, а в этом совершенно не было смысла, потому что основа у нас у всех одна. И соединение этих организаций - да любая консолидация - послужит увеличению эффективности.

LXF: Вы считаете, что это также позволит прояснить цели?
ЯМ: Да, в том смысле, например, что вместо того, чтобы распыляться на LSB, CGL и Portland, мы сможем объединить их под одной идеей, а именно идеей стандартизации платформы Linux. Это повлечет за собой работу над компилятором, инструментарием, ядром, рабочим столом, некоторыми вертикальными функциями, например, телекоммуникационными, которые нацелены на определенную сферу.
Нам надо придумать четкое пояснение того, чем мы занимаемся. Люди обычно не задумываются об организациях, занимающихся стандартами. Они не думают «Какими стандартами занимается эта группа?» Они думают так: «А что это за штуковина такая - Linux, и как бы мне в него залезть?», «Как мне создать свой продукт для него?», «Как мне использовать его в моем предприятии?» - и далее в том же роде. Нам надо говорить на их языке - а помимо этого, просто засучить рукава и делать то, что должно быть сделано.

LXF: А вас не беспокоит, что в некоторых стандартах будут использованы патенты?
ЯМ: Об этом приходится беспокоиться всем, кто занимается стандартами.

LXF: Потому что так уже случалось, причем многократно.
ЯМ: Да, я полагаю, это уже проверенная временем технология: принять участие в разработке стандарта и внести свой вклад. Это называется подводными патентами: такие штуки скрываются где-то на заднем плане. Вы уже заняли нужную позицию, закрутили болты... Поскольку это - проверенная временем технология, организации, занимающиеся стандартами, разработали свою политику, а также и политику отношения к собственности, которая как раз и создана для подобных вопросов.
Мы - не исключение. У нас тоже есть политика IP, созданная для того, чтобы не возникали проблемы подобного рода. Конечно, наша политика отличается от практикуемой в типичных организациях, занимающихся стандартами, потому что мы - Open Source, но все же в большинстве случаев правила те же.