1.2 Практическая интеграция

Сильными техническими сторонами открытых ОС, выгодно отличающими их от любых альтернатив в плане практической интеграции (разворачивания, поддержания в работоспособном состоянии, непротиворечивого расширения и наращивания), являются:

поддержка широкого спектра аппаратных платформ (самыми «всеядными» являются системы на основе ядра «Линукс»);

поддержка различных топологий многопользовательских систем: от совокупности независимых рабочих станций до многотерминальных систем, в том числе, включающих компьютеры на разных аппаратных платформах.

В качестве существенной проблемы, сдерживающей стандартизацию во многих категориях систем, часто называют сложности с поддержкой многих устройств «потребительского» класса, ориентированных на архитектуры «IA-32» (IBM PC-совместимые) и «PowerPC» («Макинтоши»). Поставщики таких устройств нередко утаивают важные технические параметры и другую информацию, необходимую для разработки драйверов для своих видеокарт, модемов и пр.

Мы склонны считать это скорее проблемой в политике закупок, чем проблемой открытых ОС. Помимо всего прочего, владельцы таких изделий сплошь и рядом сталкиваются со сложностями и при смене версий ОС, поддерживаемых их поставщиками (производитель может прекратить свое существование или поддержку конкретного устройства или поссориться с разработчиком самой такой ОС). При приобретении оборудования, которое будет эксплуатироваться длительное время, всегда следует обращать внимание на доступность технической документации[6], а не только «пользовательских инструкций».

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

Топологии. Вообще говоря, топологии вычислительных систем (например, учебных классов) можно разделить на следующие категории.

1. Совокупность автономных рабочих станций (standalone WS; персональных компьютеров). Каждая станция содержит копию ОС и необходимых прикладных пакетов, пользовательские файлы хранятся также на локальном диске. Эта топология исключает затраты на разворачивание и поддержание локальной сети, однако без всякого преувеличения ее можно назвать «администраторским адом»: даже такая простая операция как обновление какого-либо программного пакета, требует «врачебного обхода» всех машин, которых может быть и десяток, и сотня. Кроме того, на пользователей ложится забота о воспроизведении своих данных в следующем сеансе (например, сохранением их на съемный носитель или жестким закреплением мест в классе за пользователями), что отнимает массу времени и приводит к неразберихе. Сильной ее стороной является высокая «живучесть»: выход из строя любого устройства означает в худшем случае утрату работоспособности одного рабочего места.

2. Система рабочих станций без данных (dataless WS). Рабочая станция без данных также содержит локальную копию ОС и прикладных пакетов, однако рабочие каталоги пользователей хранятся на файл-сервере локальной сети, объединяющей станцию. Та же сеть может использоваться и для централизованного администрирования систем, и встроенные административные средства открытых систем делают выполнение типовых процедур достаточно эффективным. Однако возрастают издержки за счет расходов на сеть и рисков выхода из строя сервера, что повлечет за собой неработоспособность целого класса или нескольких классов.

3. Система бездисковых (diskless) рабочих станций. Бездисковые рабочие станции подобны рабочим станциям без данных с тем дополнением, что не только данные, но и ОС и прикладные программы хранятся на файл-сервере. Сеть бездисковых станций предъявляет более высокие требования к производительности сервера и сети, чем сеть станций без данных, однако сами станции несколько дешевле, и администрировать такую систему еще проще.

4. Система терминалов («тонких клиентов») и прикладного сервера. В отличие от сети рабочих станций («толстых клиентов»), концепция «тонких клиентов» предполагает, что на рабочем месте исполняются только терминальные функции, а сами программы (и системные, и прикладные) запускаются на выделенном сервере. Эта топология предъявляет самые высокие требования к производительности и надежности сервера и сети, зато сами терминалы могут быть очень дешевыми и при этом надежными (нагрузка на процессор в терминале невысока, он может работать без принудительного охлаждения, диска в терминале нет в принципе, таким образом, X-терминал может быть собран вообще без движущихся частей).

(Интересной «вариацией на тему» является разработка Московского государственного индустриального университета «Горыныч», представляющая собой двух— или трехтерминальный комплекс, собранный на основе одного IBM PC-совместимого системного блока и работающий под управлением ОС «ГНУ/Линукс» (www.ctc.msiu.ru). Отличие от классической терминально-серверной архитектуры заключается в том, что дополнительные «терминалы» (видеоадаптеры и USB-клавиатуры и мыши) включаются не в локальную сеть, а в шину отдельного компьютера.).

5. Смешанные топологии. В одной и той же сети могут сосуществовать терминалы с рабочими станциями. Кроме того, машины с маргинальной производительностью могут использоваться в качестве рабочих станций при запуске «легких» (нетребовательных к ресурсам) программ и как терминалы — при исполнении «тяжелых» (ресурсоемких).

Существуют методики выбора оптимальной топологии исходя из профиля рабочих задач, конъюнктуры рынка и параметров уже эксплуатируемого оборудования. Скорее всего, в отличие от коммерческой среды, в реальных сегодняшних школьных условиях, включающих хроническое недофинансирование и спорадические, зависящие больше от вышестоящих органов, чем от самих школ, закупки и поставки оборудования, эти методики редко применимы. Однако сама гибкость топологии позволяет эффективным образом использовать и вновь приобретаемое, и уже имеющееся, и устаревающее оборудование.

Подбор оборудования. Все элементы перечисленных топологий, включая терминалы, рабочие станции и серверы, могут реализоваться на основе самого массового IBM PC-совместимого оборудования. Кроме того, можно задействовать менее распространенные PowerPC— и UltraSPARC-машины, а также старые «Макинтоши» на основе Motorola 68K (в качестве терминалов). В нашу школу вряд ли попадет что-то более экзотическое.

Стартовая мощность X-терминала — Intel 486DX-66 или эквивалентный по производительности процессор (хотя теория показывает возможность запуска X на процессорах i486SX и i386, нам не доводилось видеть, чтобы это приводило к удовлетворительным результатам) с 16 МБ памяти.

Рекомендуемый начальный уровень рабочих станций — PII600 или Celeron 800 со 128 МБ ОЗУ (многие программы могут нормально эксплуатироваться при гораздо меньшей производительности).

Для нормальной работы в бездисковой топологии сеть желательна (а при терминальной — необходима) как минимум 100-мегабитная.

Производительность серверов необходимо расчитывать; на сайтах производителей можно найти методики оценки.

Как уже отмечалось, нужно по возможности следить за доступностью технической документации на комплектующие (или, что то же самое, за их присутствием в списках аппаратной совместимости ведущих поставщиков «Линукс»— и «БСД»-систем).

Рекомендуемые параметры мониторов определяются Гигиеническими требованиями, принимаемыми Министерством образования; практика показывает, что их лучше соблюдать.

Еще один совет, который можно найти в рекомендациях по интеграции, устарел: одно время были популярны упрощенные «мыши» без средней кнопки, работать с которыми в современных графических средах не слишком удобно, и их рекомендовали избегать, однако сегодня большинство «мышей» снабжены колесом прокрутки, также действующим как средняя кнопка.

Администрирование. К задачам администрирования относится установка и обновление программ и пакетов, управление пользователями (распределение полномочий), резервное копирование данных, определение технической политики взаимодействия системы со внешними сетями и т.п.

Плохая новость заключается в том, что администратор — дорогая рабочая сила. Хорошая — в том, что при правильном проектировании и разворачивании системы последующее администрирование требует минимальных усилий.

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

«ГНУ/Линукс» и «БСД». Существуют два распространенных мифа относительно дистрибутивов, основанных на ядре «Линукс», с одной стороны, и восходящих к «БСД» — с другой.

Первый из них заключается в том, что «“Линукс” — для клиентов, “БСД” — для серверов». Это неправда не только в части «Линукс»-систем, «прекрасно чувствующих себя» на серверах, но и в отношении «БСД», совершенно нормально приспособленной для «настольного» применения (по крайней мере, в ипостаси FreeBSD).

Второй сводится к тому, что «“Линукс” под GPL, “БСД” под “БСД”-лицензией». На самом деле, как «БСД»-, так и «ГНУ/Линукс»-дистрибутивы включают в себя множество пакетов под различными свободными лицензиями. При этом в прикладной части состав пакетов практически одинаков, да и в системной и инструментальной пересекается более чем наполовину.

Кроме этих сказок, существует масса поводов для препирательств между «фанами» этих двух концептуальных направлений свободного ПО, в каковых препирательствах мы никому не рекомендуем принимать участия. Рыночная конъюнктура сегодня такова, что в «Линукс» вкладывается больше средств, она шире используется, специфические навыки работы с ней более распространены, литература доступнее.

Реальное основное различие (помимо технических тонкостей) заключается в том, что «БСД»-сообщества более склонны к централизации, а «ГНУ/Линукс» — к диверсификации. Свободные системы «БСД» на сегодня существуют в четырех вариантах: FreeBSD, NetBSD, OpenBSD и Darwin[7]. Число известных дистрибутивов «ГНУ/Линукс» превышает сотню[8].

Большая часть нижеприведенной информации для перспективных пользователей «БСД» не нужна.

Дистрибутивы. «Дистрибуция» означает «распространение» или «распределение». В товарной экономике «дистрибутор» — фирма, занятая передачей продукции от производителя розничной торговле, которая может играть сколь угодно активную роль в маркетинге, но на товар прямого влияния не оказывает.

В программном обеспечении «разработчик дистрибутива» — важное активное звено в процессах разработки, использования и применения программ. Его роль не менее важна, чем роль разработчиков отдельных программ.

Сила свободного ПО не только в том, что любая программа может свободно использоваться как таковая (включая ее модификацию и распространение) (система на основе «Линукс» может быть собрана полностью «вручную»[9], что весьма рекомендуется в курсе подготовки продвинутых администраторов и системных программистов (а также всем серьезно интересующимся тем, как системы устроены изнутри), но совершенно излишня для всех остальных), но и в том, что идеология «интеллектуальной собственности» исключена как помеха на пути объединения программ в системы.

Таким образом, конечный пользователь может получать все (или почти все) необходимые ему программы — не только составляющие операционную систему или среду, но и прикладные — из одних рук, готовыми к совместному применению, если найдется разработчик дистрибутива с близкими целями.

Первые дистрибутивы ОС на основе ядра «Линукс» («SLS» и «Slackware»; последний выпускается и сегодня, хотя больше популярен среди профессиональных администраторов, чем среди других категорий пользователей) появились десять лет назад, когда это ядро стало стабилизироваться и находить своих пользователей вне академического сообщества и сообщества системных программистов. К настоящему времени существует более сотни дистрибутивов, получивших более или менее широкую известность, и сама множественность дистрибутивов стала важной чертой и отличительным признаком ОС на ядре «Линукс».

Не стоит надеяться, что появится один «самый правильный» дистрибутив; скорее, уменьшение конкуренции в разработке дистрибутивов знаменовало бы собой кризис развития этих систем.

Когда-то бытовало чрезмерно упрощенное представление о цикле программного обеспечения, так называемая «каскадная модель». Позже стало понятно, что, коль скоро речь идет о сложных программах, а тем более о системах программ, «каскадная» идеализация неадекватна, и реальный процесс гораздо лучше описывается в терминах «спирали»; с этим связан и известный афоризм (кажется, восходящий еще к пятидесятым годам): «У разработки больших систем не бывает завершения, бывают только релизы».

Функция разработчика дистрибутива заключается не в том, чтобы просто «собрать программы в кучу», красиво упаковать и продать, а, скорее, в том, чтобы обеспечить эффективную коммуникацию между, с одной стороны, авторами программ (и прочих произведений, входящих в дистрибутивы) и, с другой, конечными пользователями, а также самих конечных пользователей. Упрощенно структуру дистрибутива можно представить как коллектив мэйнтейнеров — лиц, отвечающих за поддержание пакетов (единиц в системе) в хранилище в актуальном состоянии и системной целостности в соответствии с некоторой концепцией в интересах сообщества пользователей. На границе команды разработки и пользовательского сообщества разворачиваются сервисы, которые могут служить ресурсной подпиткой разработки дистрибутива.

Поставка очередного выпуска дистрибутива (на дисках или через Сеть) — лишь один шаг в этой коммуникации[10]. Выбор дистрибутива со стороны конечного пользователя — больше, чем просто выбор товара; по сути дела это выбор «узла присоединения к инфраструктуре». Не все аспекты функционирования ОС, а тем более, прикладных платформ и пакетов, стандартизованы, поэтому часть знаний и навыков администратора специфичны для дистрибутива.

Однако еще важнее, что дистрибутив определяет ближайший круг общения и стиль общения, в которое неизбежно вступает конечный пользователь. Большая часть литературы, в которой различные дистрибутивы сравниваются между собой[11], сосредоточена на технических различиях, однако, гуманитарные и «коммунитарные» (относящиеся к жизни сообщества) аспекты представляются более важными.

Наилучший способ выбора «своего» дистрибутива заключается, видимо, в том, чтобы познакомиться с информацией, приводимой на сайте разработчика или издателя, почитать архивы списков рассылки или форумов (обращая внимание на стиль общения, отношение к новым и менее опытным участникам обсуждений), найти нескольких пользователей с определенным опытом в близкой к вашей сфере приложения и пообщаться с ними напрямую. Полезным может оказаться набор критериев, изложенный в следующих двух разделах.

Критерии для выбора дистрибутива.

Общая пользовательская аудитория и срок существования дистрибутива. Общее правило: чем более широка аудитория, тем быстрее исправляются ошибки и тем проще найти помощь в решении той или иной задачи. По большому счету, это самый важный параметр дистрибутива, хотя и с нюансами, касающимися специфической сферы применения и языковой среды (см. следующие два пункта).

Пользовательская аудитория в сфере применения. Чем больше конечных пользователей применяют дистрибутив в вашей сфере деятельности (например, в школьной практике), тем проще найти помощь в решении специфических для этой сферы задач.

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

Местная (в географическом смысле) пользовательская аудитория. Распространение электронной почты и других приложений Интернет сделало «местный» фактор менее значимым, но не отменило его. Если рядом с вами (особенно в учебном заведении, расположенном в том же городе) накоплен серьезный опыт пользования тем или иным дистрибутивом, это серьезный довод в пользу его выбора.

Документированность. Значение имеет также документированность особенностей дистрибутива и наличие свежих переводов документации.

Консервативность/склонность к экспериментированию. Некоторые составители (такие, как «Дебиан») более склонны к консервативным, проверенным временем решениям, а некоторые (например, «РедХэт») более смелы в экспериментах. Что вам важнее: иметь самые свежие версии программ или меньшую вероятность ошибки? — Не торопитесь с ответом, для него нужны опыт и приходящая только с опытом мудрость, и ответ не будет однозначным.

Спектр поддерживаемого оборудования (HCL). Наличие формального списка поддерживаемого оборудования или (hardware compatibility list, HCL) — серьезный довод в пользу дистрибутива, особенно, если ваш парк оборудования комплектуется на случайной основе. Если у вас постоянный поставщик оборудования и он сотрудничает с кем-либо из составителей дистрибутивов — это еще более серьезный довод в пользу последнего.

Поддержка необходимых программ (состав дистрибутива в прикладной части). Как ни странно, это гораздо менее значимый параметр, чем перечисленные выше. Легче самому дополнить несколькими программами дистрибутив, в остальном удовлетворяющий вышеперечисленным критериям.

Критичность несвободных компонентов. Большинство популярных дистрибутивов (кроме Debian GNU/Linux), по крайней мере, в наиболее полном варианте, включает, помимо свободных, и несвободные программы. Правильная политика заключается в том, чтобы отделять свободное от несвободного и исключать зависимость основной функциональности от несвободных программ (например, в текущем (2.2) выпуске дистрибутива ALT Linux Master все несвободное сосредоточено на девятом диске). Важным является также свободное лицензирование (или, по крайней мере, лицензия на свободное распространение в неизменном виде) документации, каковой политики придерживаются не все разработчики.

Информационная и ценовая политика разработчика. При прочих равных, преимущественно стоит входить в отношения с поставщиком, придерживающимся полной прозрачности разработки дистрибутивов. Технически это означает свободный доступ (на чтение) к дереву разработки через cvs или ftp или, по крайней мере, простую регистрационную процедуру для получения такого доступа. Разработчики, закрывающие процесс и лишь периодически сбрасывающие его результаты в релизы, скорее всего, готовят сюрпризы своим пользователям, и редко такие сюрпризы оказываются приятными

Цена изданий на дисках обычно не играет большого значения (поскольку приобретается один-два комплекта на десятки компьютеров) и варьирует незначительно из-за конкуренции между промышленно тиражированными дистрибутивами и альтернативой самостоятельного переписывания с одолженных дисков или через Интернет. Цена «компактного» (один-три диска плюс брошюрка) дистрибутива в России — порядка 200-300 р., «обширного» (шесть-десять CD плюс несколько томов документации) — от одной до трех тыс. р. Публикация дистрибутивов на DVD, возможно, уничтожит феномен «компактного» малодискового дистрибутива и приведет к дальнейшему снижению цен[12].

Альтернативным способом получения дистрибутива является его полная или попакетная загрузка через Сеть (на сайтах разработчиков практически всегда они есть), что может оказаться дороже, но оперативнее приобретения дисков. Чаще всего пользователи сочетают приобретение комплектов дисков по мере выхода очередных релизов и загрузку по Сети исправлений и обновлений в периоды между релизами.

Технические параметры дистрибутивов.

Бинарная установка или установка из исходников? В сообществе «БСД» в качестве штатной процедуры установки принято «портирование», т.е. автоматизированная компиляция и сборка пакетов для целевой машины из исходников. В сообществе «ГНУ/Линукс» в качестве штатной процедуры установки принята распаковка бинарных (прекомпилированных) пакетов, и до недавнего времени (появления так называемых source-based дистрибутивов) все дистрибутивы технически поддерживали именно этот способ установки (хотя, разумеется, администратор мог и пересобрать любой пакет).

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

Программа установки, управление пакетами и утилиты настройки. Как уже замечено, большинство дистрибутивов «ГНУ/Линукс», включая самые популярные, предусматривают установку с первоначальной настройкой и обновление с использованием прекомпилированных программ, собранных в пакеты. Пакет, который может включать одну или более программ, файлы конфигурации, документацию и т.п. является минимальной единицей установки или обновления штатными для дистрибутива средствами. В отдельные пакеты составителями собираются также исходные коды, соответствующие прекомпилированному пакету. Процедуры установки, удаления, обновления пакетов называются управлением пакетами.

Стандарта на пакетирование и управление пакетами не существует. Распространение получили три формата пакетов: rpm (впервые появившийся в дистрибутиве RedHat и применяемый сегодня большинством составителей дистрибутивов), deb (применяемый Debian) и tgz (применяемый Slackware). На формат пакета завязаны программа установки и управления пакетами («rpm» для rpm, «setup» для tgz и «dpkg» для deb), способная отслеживать зависимости между пакетами (ситуации, когда для нормальной работы программы из одного пакета требуется программа (возможно, определенная версия) из другого пакета, или, наоборот, когда программы из разных пакетов являются взаимоисключающими в рамках одной системы).

В последние годы развиваются усовершенствованные средства управления пакетами, позволяющие преодолевать некоторые ограничения, свойственные «rpm» и «dpkg» (в частности, отслеживать ситуацию смены имени (в отличие от номера версии) пакета). В качестве примеров таких средств можно назвать «apt» (дистрибутивы Debian, ALT Linux и Conectiva) и «yum» (дистрибутив ASPLinux).

Различные системы пакетирования и управления пакетами примерно равномощны, но используют отличающийся синтаксис. Начинающему администратору проще перейти от администрирования одной системы к другой, если в них применяется одна и та же программа управления пакетами, чем к системе с другой программой управления пакетами.

Одно время среди составителей дистрибутивов было модно создавать различные «утилиты настройки», обычно с графическими интерфейсами, позволяющие выполнять некоторые административные задачи альтернативным способом. По большей части этот опыт следует признать неудачным, так как попытки администрировать систему такими утилитами обычно рано или поздно приводят ее в неуправляемое или даже неработоспособное состояние.

Аппаратные платформы. Наконец, следует обратить внимание на аппаратные платформы, на которые ориентирован дистрибутив. Более половины существующих дистрибутивов ориентированы исключительно на IA-32 (IBM PC-совместимые компьютеры), большинство остальных поддерживает две-три аппаратные платформы, а «Дебиан» — целых десять, включая достаточно экзотический. Поддержка даже ненужного вам «железа» при прочих равных, тем не менее, является признаком зрелости дистрибутива.

Обзор самых популярных дистрибутивов.

Скорее всего, реальный выбор будет идти между дистрибутивами, либо входящими в «высшую лигу» по популярности в мире (Debian, RedHat, Mandrake и SuSE), либо разрабатывающимися в России (ALT Linux и ASPLinux)[13].

ALT Linux разрабатывается международным коллективом ALT Linux Team и публикуется одноименной московской компанией. Сильной стороной ALT является достаточно структурированное русскоязычное сообщество пользователей (включающее списки рассылки, справочные серверы, деловые связи ALT Linux и пр.), слабой — отсутствие на сегодня сколько-нибудь серьезной аппаратной базы для тестирования (и, как следствие, отсутствие формального HCL). ALT неплохо документирован[14]. Дистрибутив выходит с 2001 г., хотя следует учитывать и ранний опыт той же команды, выпускавшей до того русскую версию Linux-Mandrake

ASPLinux — в значительной мере остается производным от Red Hat, причем заявляется бинарная и аппаратная совместимость с последним. ASPLinux более консервативен, чем RedHat, поставка его включает неплохую документацию на русском. Сохраняя лучшие черты RedHat, он, в большинстве случае является более интересным, чем RedHat, вариантом, по крайней мере, для начинающего российского пользователя. Выпускается с 2001 г., хотя следует иметь в виду и более ранний опыт влившейся в коллектив ASPLinux украинской команды Black Cat Linux.

Debian GNU/Linux. «Образцово-показательный» Debian — единственный из популярных дистрибутивов, принципиально разрабатываемый в некоммерческих рамках. Официальные дистрибутивы Debian содержат пакеты исключительно со свободным софтом. У Debian наиболее формализованные и прозрачные правила взаимодействия в сообществе, причем многие процедуры технологизированы. Debian поддерживает самый широкий спектр аппаратных платформ. «Коробочные» продажи этого дистрибутива невелики, но он является самым популярным среди разработчиков ПО (около половины активных раработчиков свободного ПО пользуются именно им). В России Debian GNU/Linux издается московской компанией ALT Linux, являющейся также разработчиком собственного одноименного дистрибутива (см. выше). Debian GNU/Linux существует с 1993 г.

Linux-Mandrake. Этот дистрибутив, выпускающийся французской компанией MandrakeSoft, «отпочковался» в свое время (1996 г.) от RedHat и в какой-то момент даже догнал его по количеству коробочных продаж. Парадоксальным образом достаточно высокое качество разработки не помешало компании попасть в затруднительное положение, но компания продолжает выпуск своего дистрибутива, текущая версия которого оценивается пользователями как весьма удачная и сохраняет популярность.