Сравнительный анализ операционных систем Linux и FreeBSD

Однако  перекомпиляцией ядра дело не ограничивается. Нужно еще поставить соответствующий 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 (которая сама по себе является уже частью не базовой системы, но системы портов).

И тут  уместно сказать пару слов еще об одной широко распространенной легенде – будто бы сборка из исходников посредством портообразных управляющих комплексов всегда приводит к более «чистой» (то есть свободной от лишних компонентов) системе. Это далеко не всегда так.

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

Что меня всегда удивляло в портах FreeBSD, так это ситуация со сборкой моего любимого редактора joe. Каковой в качестве зависимости непременно требовал GNU make версии 3.80, хотя собственный make входит в состав FreeBSD Distributions и собрать с его посредством joe руками не составляет никаких проблем.

А вообще «чистота» установки пакета очень зависит от конкретной реализации порта. Недавно обнаружил я в новостях сообщение о новом оконном менеджере под названием edo – небольшом, как говорилось, компактном и быстром. Обнаружился он и в портах FreeBSD, откуда я решил его собрать. В итоге этот маленький :–) WM потянул за собой (как зависимость зависимости) не что иное, как MySQL...

Однако  если вы думаете, что такое поведение  портов – особенность FreeBSD, и создатели  их Linux–клонов учли ошибки прошлого, то уверяю это не всегда так. Причем в Linux ситуация усугубляется особенностями базовой системы, точнее, несогласованностью развития отдельных ее компонентов.

Каждый, кому доводилось собирать Linux from Scratch, знает, что некоторые версии пакетов Base Linux имеют обыкновение собираться только с определенными (отнюдь не обязательно самыми свежими) версиями таких утилит, как autoconf и automake, категорически отказываясь делать это с другими их версиями (пусть даже более свежими и прогрессивными).

Разработчики Source Based дистрибутивов Linux подчас обходят эту сложность тем, что принудительно вносят в список зависимостей таких «склизких» пакетов autoconf и automake «прошлогоднего» розлива, притом, что сам по себе базовый комплект включает уже текущие на данный момент их версии. В результате чего, например, в Gentoo при выполнении бутстраппинга или emerge system можно с удивлением наблюдать, как система лезет в Интернет за бородатым, как Карл Маркс, autoconf хотя свежая его версия только что была развернута из тарбалла stage1. А если вспомнить, что многие полагают, будто по настоящему стабильное ядро Linux может быть собрано только с gcc версии 2.9.X, результатом чего оказывается присутствие в системе двух компиляторов, то о какой «чистоте» сборки можно еще говорить?

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

FreeBSD, вопреки устоявшемуся мнению, существенно проще в настройке и локальном администрировании. Даже без учета того факта, что она одна, а Linux–ов – много;

напротив, система портов FreeBSD в настоящее  время (в отличие от недавнего  прошлого), не имеет значимых преимуществ перед аналогичными инструментами из Source Based дистрибутивов Linux.

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

Пользовательские  качества 

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

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

Ибо такой  пользователь большую часть времени  проводит в Иксах, и ему абсолютно  без разницы, поверх какой операционки  эти самые Иксы крутятся. Ему только кажется, что он работает в Linux или FreeBSD (NetBSD, OpenBSD – рискну расширить я этот список). На самом деле работает он в KDE (Gnome, XFce, WindowMaker – нужное дописать). И если бы ему не пришлось предварительно устанавливать и настраивать свою операционку, он имел бы шанс никогда не узнать, в какой именно из POSIX–совместимых систем он работает: перед ним будут одни и те же интерфейсные элементы, одни и те же средства настройки и приложения.

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

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

Пользователь Linux для начала вынужден разбираться с тем, какой из двух пакетов управления консолью – kbd или console-tools применяется в его дистрибутиве. Конечно, ныне они практически идентичны по своим возможностям, но каждый имеет свой набор команд с несколько различающимся синтаксисом. А кое–какие настройки (например, цвета текста и фона) требуют от него использования команд, не входящих ни в один из пакетов. А кое–что (например, те же цвета бордюров) все равно останутся для него недоступными.

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

Конечно, и Linux располагает тем же самым  набором классических Unix–утилит (точнее, как и FreeBSD, их аналогами). Однако это  именно разобщенные пакеты, разрабатывавшиеся  в рамках проекта GNU, в сущности, независимо от операционной системы. И уже в силу этого не столь тесно интегрированные с ней и между собой.

Так что  же, в консольном режиме первенство остается за FreeBSD? По моему мнению –  безусловно. Но только если речь идет именно о чисто текстовой консоли. Если же обратить свой взгляд на т.н. графическую консоль (реализуемую посредством Frame Buffer), то все видится несколько иначе.

Начать  с того, что графическая консоль FreeBSD (т.н. Raster Mode) ограничена одним–единственным разрешением 800x600 (тут речь идет именно о настоящем пиксельном разрешении, а не плотности символов). Да и то на некоторых чипах этот режим не работает вообще, на других имеет вполне скверный вид. Собственно, нормального результата в Raster Mode мне не удавалось добиться ни на одной из имевшихся в моем распоряжении видеокарт.

В Linux же графическая консоль просто радует глаз. Даже при поддержке Frame Buffer для  абстрактных VESA–совместимых карт, можно  варьировать разрешения от 640x480 до 1280x1024, с изменением глубины цвета в  стандартном диапазоне. Что обеспечивает не только комфортный просмотр изображений, но и весьма приличное (на мой взгляд – более чем приличное) воспроизведение видео. Для карт, имеющих хорошо реализованные собственные драйвера в ядре Linux (Matrox, ATI, чипсетное видео от Intel) к этому добавляется возможность установки нестандартных разрешений экрана.

Естественно, никто не использует консоль для  работы с изображениями, и очень  немногие для просмотра видео. Почему же я придаю графической консоли  такое значение? Да потому, что незаметно, но наступает эра жидкокристаллических дисплеев, знаменующая собой смерть чисто текстового режима (но не консольного режима как такового). Почему – легко поймут те, кто видел стандартный текстовый режим 80x25 символов на 18–дюймовом LCD–мониторе с физическим разрешением матрицы 1280x1024. А как это смотрелось бы на экране с соотношением сторон 16:9 я боюсь себе даже представить...

Наконец, остается еще один вопрос, важный для пользователя 
 
 
 

О производительности 

Представление о большем быстродействии FreeBSD по сравнению с Linux–ом столь же традиционно, как и мнение о большей сложности ее настройки. Однако так ли все однозначно?

Во–первых, как один из основных критериев при  этом рассматривается скорость загрузки, корреляция которой со скоростью  исполнения приложений несколько сомнительна. Помнится, из немалого числа операционок, которые мне довелось видеть в своей жизни, быстрее всех грузилась MS DOS :–)

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

По своему сугубо пользовательскому опыту  я бы сказал, что разницы в быстродействии на пользовательских задачах между Linux и FreeBSD органолептически обычно не просматривается. За двумя исключениями, первое из которых – файловые операции.

Очевидно, что на производительность файловых операций каждой ОС влияют два фактора  – реализация взаимодействия с дисковой подсистемой (для десктопа – конкретно с интерфейсом ATA) и организация поддерживаемой файловой системы (систем). И вот тут–то FreeBSD оказывается в невыгодном по сравнению с Linux положении.

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

Такова  первая сторона вопроса. Вторая –  файловая система FreeBSD, каковыми являются UFS и (по умолчанию в 5–й ветке) ее усовершенствованная  модернизация UFS2. Традиционно в этой ОС обе используются в частично синхронном режиме (noasync mode), когда изменения метаданных файлов записываются на диск немедленно, а изменения блоков данных – кэшируются в оперативной памяти.