Поддержка звуковых карт, как сама по себе, так и механизм её реализации во FreeBSD, давно уже стала притчей во языцех. Только давайте посмотрим, а есть ли предмет разговора? Ведь фактически весь ныне существующий их ассортимент сводится к паре-тройке встроенных аудиокодеков типа AC'97 и одной-двум текущим «крутым» моделям от Creative. Относительно вторых ничего сказать не могу, ибо со времен SB AWE128 не испытывал в них ни малейшей потребности. А вот со встроенными кодеками во FreeBSD всё обстоит более чем нормально. Причём ещё с тех времён, когда их настройка в Linux'е представляла собой не вполне тривиальную задачу, во FreeBSD она обеспечивалась одной-тремя строками в конфиге ядра или загрузчика.
Предвижу возражение, что в Linux'е с тех пор звуковая система развилась до невозможных пределов, а во Free всё осталось по прежнему. Да, но так ли уж это плохо? Ведь всем известно, что если солнце всходит на востоке, заходит на западе и так — каждый день, может быть, лучше ничего не менять в этом процессе?
О поддержке принтеров, сканеров, многофункциональных и остальных устройств, говорилось столько, что повторять прописные истины (например, избегать GDI-устройств и прочих дешёвых подделок) было бы просто скучно.
Поддержка хранилищ данных
А вот поддержка средств хранения данных — вопрос для пользователя очень важный, если, конечно, его личные данные не сводятся к набору порнухи, скачанной из Интернета. И тут, казалось бы, мы видим явное лидерство Linux'а, ядро которого поддерживает массу файловых систем как нативных (а в ближайшее время число таковых обещает чуть не удвоиться), обеспечивает эффективные средства работы с программными RAID'ами и логическими томами (LVM). Чем до недавнего времени FreeBSD могла противопоставить только архаичную, не смотря на все усовершенствования, файловую систему UFS и несколько способов организации программных RAID-массивов, причём без возможности задействовать их простыми средствами.
Ныне положение изменилось, и портирование на FreeBSD системы ZFS, обеспечивающей функции как менеджера логических томов, так и собственно файловой системы, действительно ставит последнюю точку в развитии средств хранения данных на современном этапе. Ибо ни по функционалу, ни по простоте использования, ни по быстродействию ни одно из аналогичных средств Linux'а с ней состязаться не может даже в комплексе. Да, надёжность ZFS ещё не проверена временем и не вполне достаточна для использования в промышленных серверах. Но это — дело наживное (и, как показывает практика, интенсивно наживаемое). А для настольных применений ZFS более чем достаточна даже в существующем виде.
Кстати, косвенное преимущество ZFS перед всеми остальными системами организации хранилищ данных — психологическое. Поскольку система эта требует как быстрого процессора, так и большого количества оперативной памяти, душу пользователя FreeBSD будет греть мысль о том, что вычислительные мощности его современной машины не простаивают зря. И ему не будет мучительно больно за бесцельно вставленную память, лишние процессорные ядра и их запредельную тактовую частоту...
В Linux'е поддержки ZFS в нативном виде нет и, по юридическим причинам, не предвидится, а реализация её на пользовательском уровне — не совсем то, что надо. Конечно, нельзя исключить того, что кто-либо из энтузиастов возьмется за разработку сторонних патчей поддержки ZFS к ядру Linux'а, однако доведение их до ума, как показывает пример FreeBSD, потребует немалого времени, а шансов на получение ими официального статуса почти нет.
Отступление: не могу не констатировать с удовольствием, что ныне с поддержкой ZFS в Linux с технической точки зрения всё нормально (проект ZFS on Linux). Не смотря на препоны и рогатки, чинимые статусом – по прежнему далёким от официального.
И вообще, специфика разработки Linux'а в отношении файловых систем выливается в то, что энтузиасты, желающие (и могущие) этим заниматься, с большим удовольствием создают собственные велосипеды, типа BTRFS или TuxFS, нежели доводят до ума велосипеды существующие, чему примером служит печальная судьба AdvFS. Само по себе это не хорошо и не плохо — это медицинский факт. Однако именно в области файловых систем он играет роль не самую положительную...
Внутреннее устройство системы и обеспечение её целостности
Это, пожалуй, самое кардинальное различие между Linux'ом и FreeBSD. Linux — это конкреция, более или менее произвольно (по произволу майнтайнеров дистрибутивов) разрастающаяся вокруг центра кристаллизации, то есть ядра системы за счет агломерата внешних утилит и приложений, без которых она не то что использоваться, но даже и загрузиться простым способом не может. FreeBSD — монолитный кристалл, теоретически самостоятельный и самодостаточный.
Конечно, и то, и другое — в идеале. На практике и в любом дистрибутиве Linux можно выделить базовый комплекс, состоящий из примерно одного набора системных и пользовательских утилит, необходимых для старта системы и её минимальной функциональности. А FreeBSD Distributions, напротив, включает в базовый набор, с одной стороны, компоненты, вовсе не являющиеся жизненно необходимыми (типичный и наиболее часто поминаемый пример — sendmail). С другой стороны, base FreeBSD нельзя считать и полностью самодостаточным — трудно представить себе её, например, без Perl'а...
Различие, скорее, в модели разработки. Базовый комплект FreeBSD, за некоторыми (хотя и принципиально важными) исключениями, разрабатывается в рамках единого проекта. И в результате каждое изменение функциональности ядра тут же находит своё отражение в инструментах, эту функциональность реализующую. В Linux'е ядро и базовый комплект развиваются в серии независимых проектов, и отнюдь не всегда согласовано.
В результате FreeBSD имеет собственный механизм обновления и поддержания своей целостности — сакраментальные заклинания по сборке ядра и мира. В Linux'е эта задача возлагается на дистрибутив-специфические средства пакетного менеджмента, о которых речь пойдёт в следующем разделе.
Средства пакетного менеджмента
Это — вопрос в большей степени религиозный, нежели технологический. Пользователи FreeBSD гордятся (и вполне заслуженно) системой ports&packages, обеспечивающей, с одной стороны, быстроту установки приложений из бинарных пакетов, с другой — гибкость сборки их из портов.
Сравнивать Linux и FreeBSD в этом отношении напрямую невозможно: каждый из «основополагающих» дистрибутивов Linux'а имеет собственную систему пакетного менеджмента или сборки приложений, которые дают их пользователям не меньшие основания для гордости. А, скажем, верные последователи Патрика Фолькердинга испытывают чувство глубокого удовлетворения от фактического отсутствия в их дистрибутиве штатных инструментов для управления пакетами.
Как это ни парадоксально, в последней точке зрения тоже есть свой резон. Ведь при любой системе пакетного менеджмента пользователь в существенной мере зависит от произвола майнтайнера конкретного порта или пакета: ведь мнение его о необходимых (или, наоборот, лишних) зависимостях вовсе не обязано совпадать с мнением каждого пользователя. Конечно, и в системе портов, и в любой развитой системе пакетного менеджмента есть средства тем или иным способом скорректировать зависимости, предопределённые майнтайнером порта или сборщиком пакета. Но — при одном условии: если пользователь имеет дело «со знакомыми пистолетами». И при вдумчивом отношении к установке и обновлению.
Приведу простой пример из собственной недавней практики. В ходе обсуждения данной темы на POSIX.ru неожиданно был затронут вопрос о формате rpm и его истории, позднее выделенный в отдельное производство. С rpm based системами я не имел дела много лет, и потому решил во FreeBSD поставить rpm из порта — дабы хотя бы почитать, что о нём говорит тётя Маня.
Сказано — сделано: перехожу в каталог /usr/ports/archivers/rpm4/ и, не мудрствуя лукаво, набираю
# make install clean
после чего продолжаю заниматься своими делами. Через некоторое время решил поглядеть, что там у меня делается с установкой — и с удивлением обнаружил, что она всё ещё продолжается: скачиваются и собираются в качестве зависимостей TeX, Qt и ещё что-то...
Разумеется, такую ситуацию можно было бы предотвратить внимательным изучением Make-файла или списка зависимостей, например, на Freshports. Сказанным же хочу только подчеркнуть, что системы портов, как и пакетный менеджмент в стиле apt, сами по себе гарантии от неё не дают, наиболее эффективно работая в том случае, когда пользователь знает, что делает. А вот отсутствие в Slackware развитых средств управления пакетами просто заставляет относиться к их установке вдумчиво.
О сравнении производительности
Это ещё более сакральный вопрос. И ответить на него можно только в том случае, если ясно определиться, производительность чего именно сравнивается. В двух словах же я сказал бы так: на современных машинах, выполняющих набор обычных пользовательских приложений в окружении распространённых ныне графических сред, разница в производительности между Linux'ом и FreeBSD не фиксируется. Точка. Исключение — массовые файловые операции. Если до недавнего времени FreeBSD, за счёт особенностей работы с PATA-контроллерами и задумчивости своей файловой системы, однозначно (и местами весьма значительно) проигрывала Linux'у, то ныне распространение SATA-винтов выровняло ситуацию, а портирование ZFS сместило чашу весов в её пользу.
