Алексей Федорчук - Священные войны мира FOSS

Большинство известных мне инсталляторов из разных дистрибутивов Linux отличаются от Free'шного sysinstallв две противоположные стороны:

• есть установщики более простые – хотя, ИМХО, это та самая простота, которая хуже... ну сами знаете чего;

• и есть установщики более гибкие – но вот они-то уже требуют от пользователя достаточно глубоких познаний и четкого понимания сути совершаемых действий.

Наравне с Free'шным sysinstallя поставил бы (из всех мне известных) только установщик из Archlinux. Написанный, как свидетельствует его разработчик, под влиянием первого, он обеспечивает почти такое сочетание простоты и гибкости.

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

Конечно, постинсталляционная доводка не возбраняется и во FreeBSD. Однако здесь она направлена на достижение идеала, а не обеспечение базовой функциональности. Что я проиллюстрировал бы серией примеров.

Начнем с той же русификации. Сразу же после установки FreeBSD пользователь, при желании, получает полностью кириллизованную консоль. Правда – в одном-единственном варианте, с внутренней кодировкой kOI8-R, вводом в ней же и экранным выводом в кодировке DOS, да еще и с не вполне идеальными шрифтами. Но – никаких дальнейших действий по базовой русификации от него в обязательном порядке не требуется. А привести раскладки и шрифты в соответствие со своим идеалом он может и позднее. В дистрибутивах же Linux, не очень напирающих на дружественность пользователю, ручной правки пары конфигов пожалуй что не избежать. На причинах этого останавливаться не буду (для тех, кто представляет разницу между консолью в Linux и FreeBSD, они очевидны).

Конечно, в user-ориентированных дистрибутивах Linux отечественного происхождения пользователь получает стопроцентно русифицированную консоль «из коробки». Однако – выполненную в соответствии с представлениями разработчиков. Каковые отнюдь не обязаны совпадать с представлениями (и, главное, потребностями) данного конкретного пользователя. И уж в этом случае на коррекцию ему придется затратить существенно больше сил, нежели при русификации с нуля какого-либо дистрибутива из числа Source Based. В подтверждение чему – вспомним многочисленные статьи, посвященные откату в Red Hat (и Fedore'ном Core) с «прогрессивной» кодировки UTF на KOI8, пусть «бомжовскую», но вполне устраивающую многих и многих...

Русификация консоли вообще тесно связана со стилем инициационных файлов, принятых в данной системе. И тут линейный BSD-стиль с позиций пользователя выглядит много более простым, нежели принятая в Linux инициация в стиле System V, основанная на понятии runlevels , перевод которого как «уровни выполнения» способен окончательно сбить с понталыку начинающего пользователя.

Господа админы промышленных серверов возразят мне, что стиль System V позволяет гибко подключать и отключать различные стартовые сервисы. Не буду спорить. Однако часто ли такая задача встает перед настольным пользователем? Гораздо чаще его целью является убиение раз и навсегда многочисленных служб, которые майнтайнеры дистрибутива посчитали жизненно необходимыми для его счастья...

Не случайна тенденция многих современных дистрибутивов Linux – использовать BSD-стиль загрузки, примерами чему, кроме классической Slackware, и CRUX, и Gentoo. А в Archlinux понятие runlevels вообще утрачивает значение – хотя соответствующие слова в файле /etc/inittab найти можно, на практике уровни выполнения при старте системы никак не играют. А вот попыток внедрить в BSD-системы «прогрессивный» стиль System V что-то не наблюдается – не считать же таковым группировку скриптов различных служб в едином подкаталоге в /etc во FreeBSD 5-й ветки.

Что же до русификации Иксов – X, как известно, он и в Африке X. И действия по вписыванию путей к файлам с кириллическими шрифтами, коррекция клавиатурной раскладки и установка переключателя с латиницы на кириллицу окажутся неизбежными, поверх какой операционки Иксы бы ни стояли.

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

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

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

Однако перекомпиляцией ядра дело не ограничивается. Нужно еще поставить соответствующий ALSA-инструментарий (да еще, как правило, средства совместимости ее со старой звуковой системой OSS), активизировать соответствующего демона и с помощью не вполне очевидных средств обеспечить его «самовосстановление». И после всего этого опять столкнуться с неожиданностями. Например, с нежеланием мирного сосуществования ALSA и arts (звуковой системы KDE). Конечно, мне могут возразить, что это – проблемы KDE, однако во FreeBSD их не возникает вовсе.

Кстати, о доустановке инструментария (и прочих программ – для этого ведь необходима

Здесь до недавнего времени первенство безусловно принадлежало FreeBSD: система портов ее обеспечивала несравненное сочетание простоты и гибкости, всегда оставляя возможность выбора – собирать ли пакеты из исходников, или устанавливать их из бинарников. Не возбраняя и комбинацию этих методов. Из всего Linux'ового богачества по этой части с портами мог сравниться только Debian'овский apt, ассимилированный в недрах многих rpm-based дистрибутивов. Однако, хотя aptи предполагает возможность сборки собственных пакетов, основным методом при нем является использование прекомпилированных бинарников, собранных в соответствие с представлениями майнтайнера о зависимостях оных.

Ныне положение изменилось – и в Source Based дистрибутивах Linux широко используются портообразные системы, развившиеся под сильным влиянием своего FreeBSD-прототипа: портежи Gentoo, Sorcery из Sorcerer'а, порты CRUX, Archlinux Building System из одноименного дистрибутива. Они подчас превосходят своего прародителя по универсальности, гибкости, глобализации настроке или прозрачности устройства, использования и модернизации. К тому же за десятилетие своего развития порты FreeBSD стали весьма громоздким и труднообозримым сооружением, поддержание которого в актуальном состоянии представляет собой отдельную задачу. Далеко не всегда решаемую с помощью дополнительных средств типа portupgrade(которая сама по себе является уже частью не базовой системы, но системы портов).