Сравнивать 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 сместило чашу весов в её пользу.
Разумеется, только на мощных машинах. Как-то, эксперимента ради, я поставил FreeBSD с ZFS на ноутбук с Sempron'ом (одним из первых), медленным, даже по ноутбучным меркам, винчестером и 512 Мбайт памяти. Зрелище было душераздирающее. Так что, пожалуй, для реанимации относительно старого «железа» лучше подойдёт какой-либо из «легких» дистрибутивов Linux. Хотя для «железа суперстарого», в силу особенностей обращения с памятью, FreeBSD опять окажется предпочтительной — правда, также в одной из старых своих ипостасей, например, 4-й ветки.
Так какой же вывод следует из всего сказанного? Да очень простой: выбор между FreeBSD и Linux не имеет никакого отношения к технологическим особенностям той или другой системы. А определяется исключительно идеологическими, эмоциональными или эстетическими соображениями. Которых вдоволь можно найти в форумных обсуждениях...
Апрель, 2012
Эта серия заметок в наименьшей степени претендует на соответствие завету Тацита, поскольку была написана на злобу дня – и злоба эта продолжается по сей день. Или, напротив, день этой злобы ещё не кончился. Однако однако эмоции несколько отгорели, и итоговая статья, написанная уже непосредственно для этой книжки, надеюсь, будет более сдержанной (см. Большое Сравнение: Fedora, openSUSE, Ubuntu).
