CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
21.10.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дискуссионный клуб

Linux vs FreeBSD: продолжим "Священные войны"?

Содержание

Вступление

Давным-давно написал я заметку Linux или FreeBSD? Без гнева и пристрастия (первый вариант — 2004 год, последняя версия, учитывающая итоги обсуждения на форумах, — 2007 год). Много воды с тех пор утекло, немало сменилось ядер Linux'а и веток FreeBSD, менялись файловые системы, менялось "железо", мир десктопов заполнился 64-битными и многоядерными машинами. И настало время вернуться к этому вопросу на новом витке развития ОСестроения и аппаратных средств.

Благо, для возвращения к вопросу подвернулся и повод: статья morbo Сравнение FreeBSD и Linux (Debian), сопровождавшаяся обсуждением как непосредственно в блоге, так и в соответствующем топике POSIX.ru. Впрочем, всё это послужило только катализатором для кристаллизации давно созревавшего замысла.

Конечно, сравнительные достоинства различных Unix-подобных систем, в том числе и Linux vs FreeBSD, обсуждались бессчётное количество раз — на уровне идеологическом и технологическом, эмоционально или с попытками бесстрастия. И ныне затрагивать эту тему на полном серьёзе невозможно. Так что и всё сказанное ниже чересчур уж серьёзно воспринимать не надо. Но и не след забывать, что в каждой шутке есть лишь её доля. Не понимающим этого — просьба воздержаться от дальнейшего чтения во избежание отрицательных эмоций.

Если отвлечься от идеологической и эмоциональной составляющих, часто превалирующих над всем остальным, общим для всех ранее проводившихся дискуссий было одно: смешение в одной "куче" факторов, значимость которых очень зависит от сферы применения и условий оного. Или, грубо утрируя, средства сетевого администрирования одной системы сравниваются с поддержкой звуковых карт во второй. Надо сказать, с неизменно переменным результатом в обоих случаях...

Так что давайте начнём с того, что отделим мух от котлет, а котлеты — от гарнира, то есть разграничим сферы применения. Ныне сфер таких можно назвать три:

  • пользовательский сегмент — под ним мы будем понимать не столько пользователей домашних медиа-центров, сколько людей, занятых решением своих производственных задач на одной отдельно взятой машине;
  • серверный сегмент, охватывающий управление сетями и службами коллективного применения — своего рода войска тылового обеспечения для первой группы задач;
  • сегмент встраиваемых устройств — очертить его словами довольно трудно, но смысл, думаю, интуитивно понятен.

Разумеется, у каждого есть свои предпочтения, что из перечисленного считать мухами, что — котлетами, а что — гарниром. Это, во-первых. Во-вторых, и это — следствие первого, непреодолимой границы между выделенными сегментами нет: как было резонно отмечено в обсуждении на POSIX.ru, одно и то же устройство может выступать в любой из указанных ролей. А в-третьих, напротив, граница между мухами, котлетами и гарниром с течением времени становится всё более резкой. Что хорошо видно на примере эволюции мультимедии разного рода. Играя роль котлеты для их разработчиков, они, по мере превращения в привычный гарнир для своих пользователей, всё больше оказываются в амплуа мух для тех чудаков, кто по прежнему использует компьютер традиционным способом, то есть для работы.

Нечто аналогичное на наших глазах происходит со встраиваемыми устройствами, что демонстрирует в своем Железном марше Сергей Голубев. Типичный пример — сетевые накопители. Оснащенные винчестами, подчас объединёнными в RAID-массивы, такого объема, которому ещё недавно позавидовал бы data-центр средней руки, они нынче, казалось бы, прочно переместились в пользовательский сегмент. Однако не будем спешить: уверен, что очень скоро эти агрегаты будут продаваться с "предустановленными" видео- и аудиозаписями, коллекциями изображений и подборками материалов "только для взрослых". После чего прочно окучат сектор бытовых устройств.

Так что для начала определюсь со своей личной системой приоритетов. Будучи ориентированным очень традиционно и банально, я рассматриваю компьютер в первую очередь как инструмент для работы. А поскольку работа моя не связана ни с настройкой серверов, ни с сопровождением сетей, в первую очередь меня интересуют пользовательские аспекты. Так что во всём дальнейшем банкете роль котлеты предназначена настольным системам, в качестве гарнира будут выступать серверные и сетевые средства — в той мере, в какой они способствуют поеданию котлет (то есть решению пользовательских задач), а встроенным системам достанется амплуа мух, роящихся где-то далеко на кухне. Критика этой позиции со стороны приверженцев иной системы приоритетов не принимается. А вот связное и последовательное изложение их позиции — напротив, приветствуется.

Теперь про области сравнения. Традиционно Linux и FreeBSD сравниваются с точки зрения:

  • поддержки аппаратных платформ;
  • поддержки дополнительного оборудования внутри одной архитектуры;
  • поддержки хранилищ данных, таких, как логические тома и файловые системы;
  • внутреннего устройства системы и средств поддержки её целостности;
  • средств управления дополнительным программным обеспечением;
  • наконец, производительности.

Не будем отступать от этой традиции и мы. Однако главной нашей задачей будет не столько собственно сравнение, сколько определение веса каждого из сравниваемых компонентов для указанной выше сферы применения — то есть десктопной котлеты, в сравнении с серверным гарниром; встраиваемых мух я вынужден оставить без внимания, так как с оными никогда не общался.

Поддержка аппаратных платформ

Итак, поддержка аппаратных платформ. Да, Linux поддерживает их существенно больше, нежели FreeBSD (хотя до уровня Net- и даже OpenBSD существенно не дотягивает).

Актуально ли это для сферы десктопного применения? Увы, отнюдь нет. На протяжении многих лет я не устаю вспоминать статью в журнале PC Mafazine, опубликованную лет пятнадцать назад под названием (по памяти) Через 10 лет все платформы, кроме IBM PC, уйдут в небытие.

Ныне в пользовательском сегменте это можно считать свершившимся фактом: единственной настольной платформой сейчас является x86_64 (она же AMD64), чистый i386 скоро можно будет найти только у старьёвщиков и торговцев антиквариатом. Платформа PowerPC прекратила своё существование с переходом Macintosh'ей на Intel. Платформа Cell в универсально-настольной своей ипостаси, не смотря на возлагавшиеся на неё надежды, похоже, умерла ещё на стадии зачатия. О доле Sparc'ов, Alpha. Power и прочих Itanium'ов в настольных системах можно не говорить, верно?

Так что возникает вопрос: зачем нужна многоплатформенность на столе? Для поддержки старого железа? Старые Alpha или Sparc благополучно доживают свой век со своими родными старыми же операционками. Конечно, в истории известны случаи гальванизации старых Sun'овских станций путём установки Linux'а, вместо морально самортизированной предустановленной версии Solaris — пример такой процедуры описан в известной книге Владимира Водолазкого. Но проводился его эксперимент в уж больно специфической обстановке первой половины 90-х годов. А чем только не занимались в то время пролетарии умственного труда, вроде нас с вами...

Так может быть, версии Linux или FreeBSD для указанных выше аппаратных платформ может рассматриваться как альтернатива родным ОС? С трудом верится, что те, кто затратил изрядные, даже по ненашим масштабам, деньги на приобретение соответствующих комплексов, будут сносить предустановленные, оплаченные, тщательно заточенные под "родное железо" системы, да ещё подчас со столь же предустановленными и оплаченными, специализированными приложениями, ради сомнительного удовольствия устанавливать на них свободную ОС и столь же свободные (но далеко не всегда столь же функциональные) приложения?

На моей памяти был случай... не скажу массового, но по крайней мере организованного применения Linux'а на платформе, отличной от i386. И касалось это DEC'овских Alpha — во-второй половине 90-х годов несколько московских компьютерных фирм предлагали эти машины в самосборном исполнении, благо всё "железо" для них, кроме процессоров и материнских плат, к тому времени было уже стандартно-писишное. А вот в отношении системного софта для них были возможны варианты: VMS, True64 Unix, добавлявшие к цене каждой "тачки" очень не слабый процент, и... Linux, сам по себе обходившийся бесплатно: заказчик платил, помнится, только за усилия по установке и настройке, причём не обязательно — эту работу он, если хотел (и мог), имел возможность проделать и сам.

Итак, поддержка многочисленных платформ в настольном сегменте похвальна с точки зрения общих соображений, но не особенно востребована на практике. Более того, самое смешное, что она ударными темпами теряет актуальность и в сегменте серверном — с тех самых пор, как появились дешёвые прогопроцессорные системы на Opteron'ах. Да, амортизация серверов происходит медленно, и дорогие сервера на не-Intel'овских платформах будут крутиться ещё очень долго. Однако, по аналогии с рабочими станциями, трудно представить себе, что в процессе промышленной эксплуатации их родные операционки будут заменяться на что бы то ни было свободное.

Вообще-то говоря, я могу понять мотивы портирования Linux на архитектуры, отличные от x86. Главный из них, как мне кажется, — просто наличие соответствующей техники у разработчиков и спортивный азарт при адаптации любимой ОС для прикручивания к оной. Опять-таки, мотив веский с точки зрения just for fun, но вряд ли способствующий "концентрации сил и средств на решающем направлении".

Сложнее понять растущую тягу к многоплатформенности среди разработчиков FreeBSD — системы, изначально ориентированной на самую демократичную платформу всех времён и народов. Единственное объяснение, которое я вижу — это отработка поддержки 64-битных архитектур вообще: обратим внимание, что таковыми были все поддерживаемые FreeBSD не-Intel'овские платформы, причём поддержка эта появилась ещё до широкого распространения x86_64.

А вот поддержка 64-битных машин — это как раз актуально. Не то чтобы настольный пользователь жить без них не может — но ведь в его десктопе, если он куплен в последние пару лет, наверняка стоит процессор с 64-битными инструкциями. И вполне понятная человеческая жадность требует, чтобы его возможности использовались... ну если не на полную катушку, то хотя бы как-то.

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

Более того, перебрав 64-битные варианты нескольких дистрибутивов Linux, я обнаружил падение производительности в задачах, связанных с интенсивными дисковыми и файловыми операциями, что, в принципе, и следовало бы ожидать. Так что единственное, что реально даёт пользователю Linux'а поддержка 64-битной архитектуры — это возможность использования памяти более трёх с копейками гигабайт, если таковая имеется в наличии.

Впрочем, того же результата можно добиться и косметическими мерами — пересборкой ядра с поддержкой PAE, как это описано здесь. При этом сама по себе система остаётся не только полнофункциональной, но и 32-битной, то есть на ней можно использовать, например, фирменные драйвера для видеокарт от Nvidia или ATI/AMD, 64-битные версии которых или отстают во времени, или просто отсутствуют как класс.

Во FreeBSD с поддержкой PAE дело обстоит гораздо хуже. Конечно, и её ядро можно перекомпилировать с включением соответствующих опций, но при этом накладывается столько ограничений на многие другие подсистемы ядра, что сама по себе ОС становится практически не пригодной к использованию в мирных (то есть десктопных) целях.

Однако это более чем с лихвой окупается тем, что собственно 64-битный вариант FreeBSD функционирует более чем исправно, и на машинах с соответствующими процессорами (то есть AMD64, Intel Core 2 и более высокими) прирост производительности можно заметить даже при обычной работе, а не только на тестах. Замедление же файловых операций, вероятно, имеющее место при работе с файловой системой UFS2 (которая и сама по себе достаточно задумчива) компенсируется тем, что именно на мощных 64-битных машинах с большим количеством реальной и полностью адресуемой памяти во всём блеске начинает играть ZFS, родной поддержки которой в Linux'е в ближайшее время не предвидится.

Ныне процессор менее чем с двумя ядрами найти не проще, нежели без 64-битных инструкций. И потому поддержка многопроцессорности и параллельных вычислений видится не менее важной — правда, опять-таки в основном по причине жадности, раз деньги за второе, третье или четвертое ядро всё равно уплочены. И тут можно констатировать, что и в Linux'е, и во FreeBSD многопроцессорность в настольном сегменте играет только на одном его поле — при компиляции программ, и там, и там обеспечивая примерно одинаковый прирост производительности. Но, поскольку пользователю FreeBSD заниматься сборкой программ в среднем приходится чаще, нежели линуксоиду, то он может греть свою душу мыслью о не совсем зря потраченных деньгах.

От поддержки платформ мы плавно перекидываем сразу два мостика: один — к поддержке дополнительного оборудования, другой — к поддержке хранилищ данных. Трудно сказать, что более (или менее) важно для пользователя. И потому — просто в порядке упоминания. Итак, первым меня угораздило упомянуть вот это:

Поддержка дополнительного оборудования

Тема дополнительного оборудования столь широка, что вмещает в себя весь Коран с Шариатом, всю книгу Тариката, всю иудейскую веру, всю буддистскую веру и все христианские заблуждения. Впрочем, если исходить из круга задач, очерченного выше, её можно ощутимо сузить до видеокарт и аудиосистем, прочие же устройства рассматривать как факультативные.

Начнём с поддержки видеосистем, как наиболее существенного вопроса — хотя они и не считаются компонентом платформы, но представить себе пользовательскую машину без видеокарты ничуть не проще, нежели без процессора и памяти.

Для начала следует заметить, что сами по себе ОС Linux и FreeBSD поддерживают все карты, соответствующие стандарту VESA, то есть практически все, существующие ныне в природе. Причём собственными силами делают это как в текстовом режиме, так и графическом консольном, именуемом режимом frame buffer в Linux или pixel mode во FreeBSD.

Здесь надо развеять одно широко распространённое заблуждение: якобы Linux поддерживает графику, а FreeBSD — это одна консоль. Причём интересно, что такое можно услышать не только от совсем начинающих пользователей, но и от тех, кто окончил курсы системного администрирования Linux, причём — достаточно известные. Какие именно — не скажу, чтобы не быть несправедливым к другим таким же курсам, где вполне могут учить тому же самому.

Так что, когда речь заходит о поддержке видеосистемы, явным или не явным образом подразумевается её поддержка в оконной системе X (или, в просторечии, в Иксах). И тут надо сказать, что Иксы, практически единственной современной реализацией которых является Xorg, абсолютно одни и те же и в Linux'е, и во FreeBSD, и во всех прочих свободных Unix-подобных системах, вплоть до Solaris'а. И собственными, то есть свободными, видеодрайверами Иксов все существующие видеокарты, точнее, чипы, на которых они основаны (а их и осталось-то практически всего три ряда — от Intel, Nvidia и ATI/AMD) поддерживаются абсолютно одинаково. То есть — хорошо в отношении 2D графики и никак — в отношении графики трёхмерной.

Так что относительно различий в поддержке видеокарт в Linux'е и FreeBSD можно говорить только применительно к 3D-функциям, обеспечиваемым фирменными драйверами, причём только для видеокарт от Nvidia и ATI/AMD. И тут — да, Linux обходит FreeBSD на несколько корпусов: под него существуют драйвера от обеих фирм в 32-битных вариантах, а от Nvidia — также и в 64-битном. Тогда как для FreeBSD имеются только 32-битные фирменные "дрова" Nvidia, да и то, по отзывам, качество их реализации оставляет желать лучшего.

Однако зададимся вопросом — а насколько это практически востребовано, если отвлечься от той же естественной жадности? Ведь 3D-фурнкции необходимы только для двух вещей — игр и трёхмерных эффектов в графических средах. Важность чего с точки зрения работы равна нулю (а то и отрицательной величине). Если же говорить о трёхмерной графике профессиональной — то она требует и других видеокарт (ценовой диапазон которых испокон века начинался от тысячи условных не-рублей), и другого софта, да, пожалуй что, и совсем другой аппаратуры вообще.

Поддержка звуковых карт, как сама по себе, так и механизм её реализации во 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, потребует немалого времени, шансов на получение ими официального статуса почти нет.

И вообще, специфика разработки Linux'а в отношении файловых систем выливается в то, что энтузиасты, желающие (и могущие) этим заниматься, с большим удовольствием создают собственные велосипеды, типа BTRFS или TuxFS, нежели доводят велосипеды существующие, чему примером служит печальная судьба AdvFS. Само по себе это не хорошо и не плохо — это медицинский факт. Однако именно в области файловых систем он играет роль не самую положительную...

Внутреннее устройство системы и обеспечение её целостности

Это, пожалуй, самое кардинальное различие между Linux'ом и FreeBSD. Linux — это конкреция, более или менее произвольно (по произволу майнтайнеров дистрибутивов) разрастающаяся вокруг центра кристаллизации, то есть ядра системы за счет агломерата внешних утилит и приложений, без которых она не то что использоваться, но даже и загрузиться простым способом не может. FreeBSD — монолитный кристалл, теоретически самостоятельный и самодостаточный.

Конечно, и то, и другое — в идеале. На практике и в любом дистрибутиве Linux можно выделить базовый комплекс (то самый base 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 сместило чашу весов в её пользу.

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

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




Комментарии

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: ... :: 15 :: следующая

аноним, Wed Dec 23 14:29:42 2009:
To аноним, среда, 23 декабря 2009 г. 12:32:18:
-------------
А что, в Гугле тебя забанили?
Приучайся работать головой, в жизни пригодится.
аноним, Wed Dec 23 12:32:18 2009:
Виктор Коновалов, среда, 23 декабря 2009 г. 11:14:04:
Так доставь маны ламер юродливый. Или иди нахер и юзай винду.

ну чё, тебе мана жалко? жмёшся? кинь мана то, красноглазый? и тогда заодно ещё кинь /usr/src я их тоже забыл закачать, хочу ядро покомпилить.
аноним, Wed Dec 23 12:19:47 2009:
юродливый

Правильно писать юродивый , чурка ты деревянная.
Виктор Коновалов, Wed Dec 23 11:14:04 2009:
Так доставь маны ламер юродливый. Или иди нахер и юзай винду. Вот тебе и весь мой сказ, ублюдок.
аноним, Wed Dec 23 10:52:33 2009:
Виктор Коновалов, вторник, 22 декабря 2009 г. 20:52:46:

ты давай пости маны ещё, а то я поставил фряху а маны - забыл. трафику жалко теперь. пости, я почитаю. не мешало бы man ipfw.
аноним, Wed Dec 23 10:39:52 2009:
А.Ф."Так что давайте начнём с того, что отделим мух от котлет, а котлеты — от гарнира, то есть разграничим сферы применения."

Ха, как интересно, а с какого перепугу я должен что-то отделять? Комп - универсальная машина и система на ней должна быть универсальной.
аноним, Wed Dec 23 10:37:54 2009:
А.Ф. "Впрочем, всё это послужило только катализатором для кристаллизации гавна созревшего"...
аноним, Wed Dec 23 10:36:32 2009:
О! Еще один туалет. Ща статью прочитаю и потролю (хитро потирает руки)
Виктор Коновалов, Tue Dec 22 21:06:50 2009:
И ещё про ZFS - эта ФС предназначалась не
для древних ноутов, а скорее для современных
дисковых массивов емкостью от 2T и потребности
в оперативной памяти у неё соответствуют назначению.
А на ноутах и стареньких десктопах с 500G винтами
вполне приемлимые показатели даёт привычный UFS
Кстати 8.0-RELEASE по дефолту предлагает
размечать разделы именно как UFS2.
Кроме всего прочего я бы не спешил считать
поддержку ZFS в FreeBSD абсолютно стабильной -
всё-таки слишком рано.
Виктор Коновалов, Tue Dec 22 20:52:46 2009:
И еще - сев за мой десктоп народ обычно спрашивает
"Это какой Линукс?" - ответ прост! 8.0-RELEASE FreeBSD 8.0-RELEASE #3: Fri Dec 4 03:19:34 EET 2009 ;)
И еще:
По поводу звуковых карт.
Автор пишет о устаревшем уже на 2008 год кодеке
AC`97, но ему как теоретику это простительно.
Ну а как практик я напишу вам вот что:
dmesg | grep hda
hdac0: <ATI SB600 High Definition Audio Controller> mem 0xfebf4000-0xfebf7fff irq 16 at device 20.2 on pci0
hdac0: HDA Driver Revision: 20090624_0136
hdac0: [ITHREAD]
hdac0: HDA Codec #0: Realtek ALC660
hdac0: HDA Codec #1: Unknown Codec
pcm0: <HDA Realtek ALC660 PCM #0 Analog> at cad 0 nid 1 on hdac0
=>man snd_hda
SND_HDA(4) FreeBSD Kernel Interfaces Manual SND_HDA(4)

NAME
snd_hda -- Intel High Definition Audio bridge device driver

SYNOPSIS
To compile this driver into the kernel, place the following lines in your
kernel configuration file:

device sound
device snd_hda

Alternatively, to load the driver as a module at boot time, place the
following line in loader.conf(5):

snd_hda_load="YES"

DESCRIPTION
The High Definition (HD) Audio specification was developed by Intel as
the logical successor of the old AC'97 specification and has several
advantages, such as higher bandwidth which allows more channels and more
detailed formats, support for several logical audio devices, and general
purpose DMA channels.

The snd_hda driver is a HDA bus controller driver and HDA codecs audio
functions bridge driver that allows the generic audio driver, sound(4),
to be used with this hardware. Only audio functions are supported by
snd_hda. Modem, HDMI and other possible functions are not implemented.

The snd_hda driver supports hardware that conforms with revision 1.0 of
the Intel High Definition Audio specification and tries to behave much
like the Microsoft Universal Audio Architecture (UAA) draft (revision
0.7b) for handling audio devices.

According to HDA and UAA specifications, depending on the number of HDA
buses and codecs present in system, their audio capabilities and BIOS
provided configuration, the snd_hda driver often provides several PCM
audio devices. For example, one device for main rear 7.1 output and
inputs, one device for independent headset connectors at front and one
device for SPDIF or HDMI audio input/output. The assignment of audio
inputs and outputs may be tuned with device.hints(5). The driver's ver-
bose boot messages provide a lot of information about the operation of
the driver and present audio setup.

The default audio device may be tuned by setting the hw.snd.default_unit
sysctl, as described in sound(4), or explicitly specified in application
settings.

Boot-time Configuration
The following variables are available at boot-time through the
device.hints(5) file:

hint.hdac.%d.config Configures a range of possible options. Pos-
sible values are: ``dmapos'', ``eapdinv'',
``gpio0'', ``gpio1'', ``gpio2'', ``gpio3'',
``gpio4'', ``gpio5'', ``gpio6'', ``gpio7'',
``gpioflush'', ``ivref'', ``ivref50'',
``ivref80'', ``ivref100'', ``fixedrate'',
``forcestereo'', ``ovref'', ``ovref50'',
``ovref80'', ``ovref100'', ``senseinv'',
``softpcmvol'', and ``vref''. An option pre-
fixed with ``no'', such as ``nofixedrate'',
will do the opposite and takes precedence.
Options can be separated by whitespace and
commas. ``GPIOs'' are a codec's General Pur-
pose I/O pins which system integrators some-
times use to control external muters, ampli-
fiers and so on. If you have no sound, or
sound volume is not adequate, you may have to
experiment a bit with the GPIO setup to find
the optimal setup for your system. The
``ivrefX'' and ``ovrefX'' options control the
voltage used to power external microphones.

hint.hdac.%d.msi Controls MSI (Message Signaled Interrupts)
support.

hint.hdac.%d.cad%d.nid%d.config
Overrides codec pin configuration set by BIOS.
May be specified as a 32-bit hexadecimal value
with a leading ``0x'', or as a set of space-
separated ``option=value'' pairs.

Pin configuration is the UAA driver's main source of information about
codec usage. This information is usually provided by the codec manufac-
turer and tuned by system integrators for specific system requirements.
The snd_hda driver allows users to override it to fix integrator mistakes
or to use the available codec in alternative ways (for example to get
stereo output and 2 inputs instead of a single 5.1 output).

The following options are supported:

as Association number. Associations are used to group indi-
vidual pins to form a complex multi-pin device. For exam-
ple, to group 4 connectors for 7.1 output, or to treat
several input connectors as sources for the same input
device. Association numbers can be specified as numeric
values from 0 to 15. A value of 0 means disabled pin. A
value of 15 is a set of independent unassociated pins.
Each association includes only pins of the same direction
(in/out) and is detected atomically (all pins or none). A
separate PCM audio device is created for every pair of
input and output associations.

seq Sequence number. A unique, per-association number used to
order pins inside the particular association. Sequence
numbers can be specified as numeric values from 0 to 15.

The sequence number 15 has a special meaning for output
associations. Output pins with this number and device
type ``Headphones'' will duplicate (with automatic mute if
jack detection is supported) the first pin in that associ-
ation.

device Device type. Can be specified as a number from 0 to 15 or
as a name: ``Line-out'', ``Speaker'', ``Headphones,''
``CD'', ``SPDIF-out'', ``Digital-out'', ``Modem-line'',
``Modem-handset'', ``Line-in'', ``AUX'', ``Mic'',
``Telephony'', ``SPDIF-in'', ``Digital-in'', ``Res.E'', or
``Other''. The device type also describes the pin direc-
tion (in/out). For example, ``CD'' always means an input
pin, while ``Headphones'' always means an output.

conn Connection type. Can be specified as a number from 0 to
3. The connection type can also be specified as one of
the special names ``Jack'', ``None'', ``Fixed'', or
``Both''. Pins with a connection type of ``None'' are
disabled.

ctype Connector physical type. Can be specified as a number
from 0 to 15. This is a reference only value. It is
ignored by the snd_hda driver.

color Connector color. Can be specified as a number from 0 to
15 or as one of the names ``Unknown'', ``Black'',
``Grey'', ``Blue'', ``Green'', ``Red'', ``Orange'',
``Yellow'', ``Purple'', ``Pink'', ``Res.A'', ``Res.B'',
``Res.C'', ``Res.D'', ``White'', or ``Other''. This is a
reference only value. It is ignored by the snd_hda
driver.

loc Connector physical location. Can be specified as a number
from 0 to 63. This is a reference only value. It is
ignored by the snd_hda driver.

misc Misc bits. Can be specified as a number from 0 to 15.
Bit 0 has a special meaning. When set it means that jack
detection is not implemented in hardware.

Runtime Configuration
The following sysctl(8) variables are available in addition to those
available to all sound(4) devices:

dev.hdac.%d.polling Enables polling mode. In this mode the driver
operates by querying the device state on timer
ticks using callout(9) instead of interrupts.
Polling is disabled by default. Do not enable
it unless you are facing weird interrupt prob-
lems or if the device cannot generate inter-
rupts at all.

dev.hdac.%d.polling_interval
Controller/Jack Sense polling interval (1-1000
ms)

dev.hdac.%d.pindump Setting this to a non-zero value dumps the
current pin configuration, main capabilities
and jack sense status to console and syslog.

EXAMPLES
Taking HP Compaq DX2300 with Realtek ALC888 HDA codec for example. This
system has two audio connectors on a front side, three audio connectors
on a rear side and one internal speaker. According to verbose driver
output and the codec datasheet, this codec has five stereo DACs and two
stereo ADCs, all of them are routable to any codec pin (external connec-
tor). All codec pins are reversible (could be configured either as input
or output).

So high codec uniformity and flexibility allow driver to configure it in
many different ways, depending on requested pins usage decribed by pins
configuration. The driver reports such default pin configuration when
verbose messages enabled:

hdac0: nid 20 0x01014020 as 2 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0
hdac0: nid 21 0x99130110 as 1 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1
hdac0: nid 22 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1
hdac0: nid 23 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1
hdac0: nid 24 0x01a19830 as 3 seq 0 Mic Jack jack 1 loc 1 color Pink misc 8
hdac0: nid 25 0x02a1983f as 3 seq 15 Mic Jack jack 1 loc 2 color Pink misc 8
hdac0: nid 26 0x01813031 as 3 seq 1 Line-in Jack jack 1 loc 1 color Blue misc 0
hdac0: nid 27 0x0221401f as 1 seq 15 Headphones Jack jack 1 loc 2 color Green misc 0
hdac0: nid 28 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1
hdac0: nid 30 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1
hdac0: nid 31 0x411111f0 as 15 seq 0 Speaker None jack 1 loc 1 color Black misc 1

Here we can see, that the nodes with ID (nid) 25 and 27 are front panel
connectors (Jack, loc 2), nids 20, 24 and 26 are rear panel connectors
(Jack, loc 1) and nid 21 is a built-in speaker (Fixed, loc 25). Pins
with nids 22, 23, 28, 30 and 31 will be disabled by driver due to "None"
connectivity. So the pin count and description matches to connectors that
we have.

Using association (as) and sequence (seq) fields values pins are grouped
into 3 associations:

hdac0: Association 0 (1) out:
hdac0: Pin nid=21 seq=0
hdac0: Pin nid=27 seq=15
hdac0: Association 1 (2) out:
hdac0: Pin nid=20 seq=0
hdac0: Association 2 (3) in:
hdac0: Pin nid=24 seq=0
hdac0: Pin nid=26 seq=1
hdac0: Pin nid=25 seq=15

Each pcm(4) device uses two associations: one for playback and one for
recording. Associations processed and assigned to pcm(4) devices in
increasing numerical order. In this case association #0 (1) will become
pcm0 device playback, using the internal speakers and Headphones jack
with speaker automute on the headphones jack connection. Association #1
(2) will become pcm1 playback, using the Line-out jack. Association #2
(3) will become pcm0 recording, using the external microphones and the
Line-in jack.

The snd_hda driver provides extensive verbose messages to diagnose its
operation logic and describe its current codec configuration.

Using device.hints(5) it is possible to modify the configuration of the
existing pins, allowing a broad range of different audio setups. Here
are a few examples of some setups possible for this particular hardware:

Example 1
Setting the device.hints(5) options

hint.hdac.0.cad0.nid20.config="as=1"
hint.hdac.0.cad0.nid21.config="as=2"

will swap line-out and speaker functions. So the pcm0 device will play
to the line-out and headphones jacks. Line-out will be muted on the head-
phones jack connection. Recording on pcm0 will go from two external
microphones and line-in jacks. pcm1 playback will go to the internal
speaker.

Example 2
Setting the device.hints(5) options

hint.hdac.0.cad0.nid20.config="as=1 seq=15 device=Headphones"
hint.hdac.0.cad0.nid27.config="as=2 seq=0"
hint.hdac.0.cad0.nid25.config="as=4 seq=0"

will split the headphones and one of the microphones to a separate
device. The pcm0 device will play to the internal speaker and to the
line-out jack, with speaker automute on the line-out jack connection.
Recording on pcm0 will use input from one external microphone and the
line-in jacks. The pcm1 device will be completely dedicated to a headset
(headphones and mic) connected to the front connectors.

Example 3
Setting the device.hints(5) options

hint.hdac.0.cad0.nid20.config="as=1 seq=0"
hint.hdac.0.cad0.nid26.config="as=2 seq=0"
hint.hdac.0.cad0.nid27.config="as=3 seq=0"
hint.hdac.0.cad0.nid25.config="as=4 seq=0"
hint.hdac.0.cad0.nid24.config="as=5 seq=0 device=Line-out"
hint.hdac.0.cad0.nid21.config="as=6 seq=0"

will give 4 independent devices: pcm0 (line-out and line-in), pcm1
(headphones and mic), pcm2 (additional line-out via retasked rear mic
jack), and pcm3 (internal speaker).

Example 4
Setting the device.hints(5) options

hint.hdac.0.cad0.nid20.config="as=1 seq=0"
hint.hdac.0.cad0.nid24.config="as=1 seq=1 device=Line-out"
hint.hdac.0.cad0.nid26.config="as=1 seq=2 device=Line-out"
hint.hdac.0.cad0.nid21.config="as=2 seq=0"

will give 2 devices: pcm0 for 5.1 playback via 3 rear connectors (line-
out and retasked mic and line-in) and headset (headphones and mic) at
front connectors. pcm1 for internal speaker playback. On headphones
connection rear connectors will be muted.

HARDWARE
The snd_hda driver supports many Intel HDA compatible audio chipsets
including the following:

o ATI SB450
o ATI SB600
o Intel 631x/632xESB
o Intel 82801F (ICH6)
o Intel 82801G (ICH7)
o Intel 82801H (ICH8)
o Intel 82801I (ICH9)
o Intel 82801J (ICH10)
o Intel US15W (SCH)
o nVidia MCP51
o nVidia MCP55
o nVidia MCP61A
o nVidia MCP61B
o nVidia MCP63
o nVidia MCP65A
o nVidia MCP65B
o nVidia MCP67A
o nVidia MCP67B
o nVidia MCP68
o nVidia MCP69
o SiS 966
o VIA VT8251/8237A

The following and many other codecs have been verified to work:

o Analog Devices AD1981HD
o Analog Devices AD1983
o Analog Devices AD1984
o Analog Devices AD1986A
o Analog Devices AD1988
o Analog Devices AD1988B
o CMedia CMI9880
o Conexant CX20549 (Venice)
o Conexant CX20551 (Waikiki)
o Conexant CX20561 (Hermosa)
o Realtek ALC260
o Realtek ALC262
o Realtek ALC268
o Realtek ALC660
o Realtek ALC861
o Realtek ALC861VD
o Realtek ALC880
o Realtek ALC882
o Realtek ALC883
o Realtek ALC885
o Realtek ALC888
o Realtek ALC889
o Sigmatel STAC9205
o Sigmatel STAC9220
o Sigmatel STAC9220D / 9223D
o Sigmatel STAC9221
o Sigmatel STAC9221D
o Sigmatel STAC9227D
o Sigmatel STAC9227X
o Sigmatel STAC9228D
o Sigmatel STAC9228X
o Sigmatel STAC9229D
o Sigmatel STAC9229X
o Sigmatel STAC9230D
o Sigmatel STAC9230X
o Sigmatel STAC9271D
o Sigmatel STAC9872AK
o VIA VT1708
o VIA VT1708B
o VIA VT1709

SEE ALSO
sound(4), snd_ich(4), device.hints(5), loader.conf(5), sysctl(8)

HISTORY
The snd_hda device driver first appeared in FreeBSD 6.3.

AUTHORS
The snd_hda driver was written by Stephane E. Potvin
<sepotvin@videotron.ca>, Ariff Abdullah <ariff@FreeBSD.org> and Alexander
Motin <mav@FreeBSD.org>. This manual page was written by Joel Dahl
<joel@FreeBSD.org>, Alexander Motin <mav@FreeBSD.org> and Giorgos
Keramidas <keramida@FreeBSD.org>.

BUGS
A few Hardware/OEM vendors tend to screw up BIOS settings, thus rendering
the snd_hda driver useless, which usually results in a state where the
snd_hda driver seems to attach and work, but without any sound. Some of
that cases can be solved by tuning loader.conf variables. But before try-
ing to fix problem that way, make sure that problem is really exists and
the PCM audio device you are using really corresponds to expected audio
connector.

Due to OSS limitation multichannel (not multidevice) playback is not sup-
ported.

FreeBSD 8.0 January 7, 2009 FreeBSD 8.0

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: 4 :: ... :: 15 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds