Не стоит надеяться, что появится один «самый правильный» дистрибутив; скорее, уменьшение конкуренции в разработке дистрибутивов знаменовало бы собой кризис развития этих систем.
Когда-то бытовало чрезмерно упрощенное представление о цикле программного обеспечения, так называемая «каскадная модель». Позже стало понятно, что, коль скоро речь идет о сложных программах, а тем более о системах программ, «каскадная» идеализация неадекватна, и реальный процесс гораздо лучше описывается в терминах «спирали»; с этим связан и известный афоризм (кажется, восходящий еще к пятидесятым годам): «У разработки больших систем не бывает завершения, бывают только релизы».
Функция разработчика дистрибутива заключается не в том, чтобы просто «собрать программы в кучу», красиво упаковать и продать, а, скорее, в том, чтобы обеспечить эффективную коммуникацию между, с одной стороны, авторами программ (и прочих произведений, входящих в дистрибутивы) и, с другой, конечными пользователями, а также самих конечных пользователей. Упрощенно структуру дистрибутива можно представить как коллектив мэйнтейнеров – лиц, отвечающих за поддержание пакетов (единиц в системе) в хранилище в актуальном состоянии и системной целостности в соответствии с некоторой концепцией в интересах сообщества пользователей. На границе команды разработки и пользовательского сообщества разворачиваются сервисы, которые могут служить ресурсной подпиткой разработки дистрибутива.
Поставка очередного выпуска дистрибутива (на дисках или через Сеть) – лишь один шаг в этой коммуникации[10]. Выбор дистрибутива со стороны конечного пользователя – больше, чем просто выбор товара; по сути дела это выбор «узла присоединения к инфраструктуре». Не все аспекты функционирования ОС, а тем более, прикладных платформ и пакетов, стандартизованы, поэтому часть знаний и навыков администратора специфичны для дистрибутива.
Однако еще важнее, что дистрибутив определяет ближайший круг общения и стиль общения, в которое неизбежно вступает конечный пользователь. Большая часть литературы, в которой различные дистрибутивы сравниваются между собой[11], сосредоточена на технических различиях, однако, гуманитарные и «коммунитарные» (относящиеся к жизни сообщества) аспекты представляются более важными.
Наилучший способ выбора «своего» дистрибутива заключается, видимо, в том, чтобы познакомиться с информацией, приводимой на сайте разработчика или издателя, почитать архивы списков рассылки или форумов (обращая внимание на стиль общения, отношение к новым и менее опытным участникам обсуждений), найти нескольких пользователей с определенным опытом в близкой к вашей сфере приложения и пообщаться с ними напрямую. Полезным может оказаться набор критериев, изложенный в следующих двух разделах.
Критерии для выбора дистрибутива.
Общая пользовательская аудитория и срок существования дистрибутива. Общее правило: чем более широка аудитория, тем быстрее исправляются ошибки и тем проще найти помощь в решении той или иной задачи. По большому счету, это самый важный параметр дистрибутива, хотя и с нюансами, касающимися специфической сферы применения и языковой среды (см. следующие два пункта).
Пользовательская аудитория в сфере применения. Чем больше конечных пользователей применяют дистрибутив в вашей сфере деятельности (например, в школьной практике), тем проще найти помощь в решении специфических для этой сферы задач.
Пользовательская аудитория в языковой среде. Воспользоваться преимуществами развитого пользовательского сообщества может помешать языковой барьер. Важным, таким образом, является наличие достаточного количества пользователей с родным (или хорошо знакомым) для вас языком. Ее наличие (и присутствие в команде людей, пользующихся или хотя бы знакомых с родным для вас языком) также важно в плане отсутствия проблем (или легкости их решения) с локализацией.
Местная (в географическом смысле) пользовательская аудитория. Распространение электронной почты и других приложений Интернет сделало «местный» фактор менее значимым, но не отменило его. Если рядом с вами (особенно в учебном заведении, расположенном в том же городе) накоплен серьезный опыт пользования тем или иным дистрибутивом, это серьезный довод в пользу его выбора.
Документированность. Значение имеет также документированность особенностей дистрибутива и наличие свежих переводов документации.
Консервативность/склонность к экспериментированию. Некоторые составители (такие, как «Дебиан») более склонны к консервативным, проверенным временем решениям, а некоторые (например, «РедХэт») более смелы в экспериментах. Что вам важнее: иметь самые свежие версии программ или меньшую вероятность ошибки? – Не торопитесь с ответом, для него нужны опыт и приходящая только с опытом мудрость, и ответ не будет однозначным.
Спектр поддерживаемого оборудования (HCL). Наличие формального списка поддерживаемого оборудования или (hardware compatibility list, HCL) – серьезный довод в пользу дистрибутива, особенно, если ваш парк оборудования комплектуется на случайной основе. Если у вас постоянный поставщик оборудования и он сотрудничает с кем-либо из составителей дистрибутивов – это еще более серьезный довод в пользу последнего.
Поддержка необходимых программ (состав дистрибутива в прикладной части). Как ни странно, это гораздо менее значимый параметр, чем перечисленные выше. Легче самому дополнить несколькими программами дистрибутив, в остальном удовлетворяющий вышеперечисленным критериям.
Критичность несвободных компонентов. Большинство популярных дистрибутивов (кроме Debian GNU/Linux), по крайней мере, в наиболее полном варианте, включает, помимо свободных, и несвободные программы. Правильная политика заключается в том, чтобы отделять свободное от несвободного и исключать зависимость основной функциональности от несвободных программ (например, в текущем (2.2) выпуске дистрибутива ALT Linux Master все несвободное сосредоточено на девятом диске). Важным является также свободное лицензирование (или, по крайней мере, лицензия на свободное распространение в неизменном виде) документации, каковой политики придерживаются не все разработчики.
Информационная и ценовая политика разработчика. При прочих равных, преимущественно стоит входить в отношения с поставщиком, придерживающимся полной прозрачности разработки дистрибутивов. Технически это означает свободный доступ (на чтение) к дереву разработки через cvs или ftp или, по крайней мере, простую регистрационную процедуру для получения такого доступа. Разработчики, закрывающие процесс и лишь периодически сбрасывающие его результаты в релизы, скорее всего, готовят сюрпризы своим пользователям, и редко такие сюрпризы оказываются приятными
Цена изданий на дисках обычно не играет большого значения (поскольку приобретается один-два комплекта на десятки компьютеров) и варьирует незначительно из-за конкуренции между промышленно тиражированными дистрибутивами и альтернативой самостоятельного переписывания с одолженных дисков или через Интернет. Цена «компактного» (один-три диска плюс брошюрка) дистрибутива в России – порядка 200-300 р., «обширного» (шесть-десять CD плюс несколько томов документации) – от одной до трех тыс. р. Публикация дистрибутивов на DVD, возможно, уничтожит феномен «компактного» малодискового дистрибутива и приведет к дальнейшему снижению цен[12].
10
Следует также понимать, что торговля коробками, как правило, не является основным бизнесом компании или команды, зарабатывающей чаще всего заказной разработкой и/или продажей услуг. Продажа коробок – низкорентабельные издательские проекты, в лучшем случае окупающие управление самим изданием.
11
Из русских публикаций в особенности отметим цикл статей Алексея Федорчука «Юникс для всех» (http://linuxshop.ru/unix4all/) и книгу: Алексей Федорчук, «Офис, графика, Web в Linux». – СПб.: BHV, 2001.
12
Ричард Столлмен. Руководство по GNU Emacs (тринадцатая редакция) – М.: Институт логики, 1999