Чтение онлайн

ЖАНРЫ

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

Федорчук Алексей Викторович

Шрифт:

Различие, скорее, в модели разработки. Базовый комплект 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 сместило

чашу весов в её пользу.

Разумеется, только на мощных машинах. Как-то, эксперимента ради, я поставил FreeBSD с ZFS на ноутбук с Sempron'ом (одним из первых), медленным, даже по ноутбучным меркам, винчестером и 512 Мбайт памяти. Зрелище было душераздирающее. Так что, пожалуй, для реанимации относительно старого «железа» лучше подойдёт какой-либо из «легких» дистрибутивов Linux. Хотя для «железа суперстарого», в силу особенностей обращения с памятью, FreeBSD опять окажется предпочтительной — правда, также в одной из старых своих ипостасей, например, 4-й ветки.

Так какой же вывод следует из всего сказанного? Да очень простой: выбор между FreeBSD и Linux не имеет никакого отношения к технологическим особенностям той или другой системы. А определяется исключительно идеологическими, эмоциональными или эстетическими соображениями. Которых вдоволь можно найти в форумных обсуждениях...

Ubuntu vs Fedora

Апрель, 2012

Эта серия заметок в наименьшей степени претендует на соответствие завету Тацита, поскольку была написана на злобу дня – и злоба эта продолжается по сей день. Или, напротив, день этой злобы ещё не кончился. Однако однако эмоции несколько отгорели, и итоговая статья, написанная уже непосредственно для этой книжки, надеюсь, будет более сдержанной (см. Большое Сравнение: Fedora, openSUSE, Ubuntu).

Вступление

Разговоры на тему, вынесенную в заголовок серии, активно ведутся уже не первый день. Вопрос, кто больше сделал для Linux'а, обсуждается не менее яро, чем два студиозуса в своё время спорили,

Кто доблестней, Кох или Вагнер? Пускай без бряцания шпор.

До недавнего времени мне не хотелось влезать в эту тему, и я ограничивался участием в вялотекущих перепалках на Юниксфоруме и в Джуйке. Однако в конце концов нервы мои не выдержали – и в результате вниманию читателей предлагается данное сочинение.

Завязкой сюжета послужила информация об отчёте Linux Foundation, посвящённая вопросу вклада в ядро Linux, сделанному различными фирмами, организациями и лицами в 2011 году. На русском языке она прозвучала, например, на OpenNet'е. Одновременно её интерпретацию озвучил Пётр Леменков в заметке «Кто разрабатывал ядро Linux в 2011 году?»

Пересказывать содержание отчёта и тем более его возможных (и/или сделанных) интерпретаций не буду. Чисто фактографически же это выглядит так: наибольший вклад в разработку ядра Linux (далее – LK), если не считать собирательного образа в лице

Большого Бухарца
Сообщества, внесли сотрудники Red Hat (которые по совместительству являются и основными разработчиками дистрибутива Fedora). Это – по количеству внесённых (и принятых) патчей. По числу же патчеодобрятелей Red Hat оставил позади даже всё сообщество, вместе взятое.

Отдельной строкой был отмечен вклад компании Microsoft, занявшей 17-е место по числу патчей. Правда, все они касаются только поддержки Linux как гостевой ОС в их собственной системе виртуализации Hyper-V. Да и объём кода невелик. Однако он разбивается на много патчей, что позволило компании войти в двадцатку сильнейших.

В сети же по следам этого отчёта «отдельно, с большим наслажденьем» комментировался вклад фирмы Canonical в развитие LK. Точнее, видимая незначительность этого вклада: в отличие от Microsoft, Canonical по числу не сподобилась причислению к «великолепной двадцатке». Дело дошло до обвинений в том, что в Ubuntu вообще не сочиняют код, а только передвигают кнопки справа налево и перекрашивают обои. Впрочем, такие мелкие «дружеские» подначки в адрес Ubuntu и Canonical последнее время стали любимым развлечением пользователей некоторых более иных дистрибутивов.

Поделиться с друзьями: