Священные войны мира FOSS

В 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 из порта — дабы хотя бы почитать, что о нём говорит тётя Маня.