Типичный пользователь будет чувствовать себя весьма неуютно, если не сможет запустить WinAmp или посмотреть видеофильм. А еще редактировать офисные документы, открывать pdf...

Короче, если использовать xBSD в качестве основной операционной системы, нам обязательно понадобиться GUI, иначе... это уже какой-то извращенный садомазохизм получится, с добровольной самоизоляцией от цивилизованного мира.

за и против

Ругая Windows, которая «тормозит» и занимает столько места на диске, сколько находит, мы забываем, что KDE (или GNOME – если кто хочет играть, а не работать) тормозит еще сильнее, а места занимает столько, что...

В отличие от LINUX, в xBSD «десктопное окружение» не ставится из коробки и требует не только танцев с бубном, но еще и толстого канала, поскольку качать придется столько, что стоимость трафика может запросто превысить цену лицензионной копии Windows Professional. Если последняя сразу ставится и работает, то xBSD требует кучи библиотек, поставленных в исходных текстах и влекущих обширные зависимости, которые, в свою очередь, влекут свои зависимости. Причем старые (и легкие) версии библиотек зачастую не удается откомпилировать той версией компилятора, что поставляется в свежих релизах xBSD, а новые — намного тяжелее, да и компилируются сложнее. Даже имея опыт работы с xBSD, собрать из нее десктоп за один день практически нереально. Одна лишь перекачка из сети и компиляция потребуют гораздо большего времени! О том, что каждая откомпилированная программа требует тестирования, скромно промолчим...

Но эти проблемы меркнут на фоне проблем с оборудованием, и в первую очередь — с видео-картами. Единственная компания, которая их изредка пишет — это NVIDIA, остальные же просто не обращают на xBSD внимания, поскольку на рынке десктопов она занимает очень узкий сегмент. Без родных или хотя бы реверсированных драйверов не удастся задействовать наивысшее разрешение и аппаратные фичи, ограничившись стандартным VGA или VESA-режимами. Разрешение, впрочем, можно настроить и вручную (если, конечно, знать, какие параметры для этого необходимо передать карте). С частотой развертки дела обстоят чуть сложнее, и приходится либо покупать LCD-монитор (у которого такого понятия просто нет) или подбирать необходимые параметры вручную. Все это требует знаний и времени, а время — деньги.

Таким образом, установка xBSD на десктоп:

1 Требует опыта работы с системой;

2 Отнимает кучу денег и времени;

3 Ограничивает «кругозор» небольшим пакетом программ.

Зачем же искусственно создавать себе проблемы? Из любви к системе? Так из-под KDE она практически ничем не отличается от того же LINUX'а. Только нормальный дистрибутив LINUX'а ставится сразу.

Сказанное нисколько не умоляет серверные возможности xBSD (серверу KDE на хрен не нужен) или чистой командной строки, которой для работы вполне достаточно. Если из LINUX'а рабочую станцию можно строить из ненависти к Microsoft'у, любви к UNIX-системам или просто от бедности, то никаких убедительных мотивов для превращения xBSD в то, чем она не является, просто нет, да и не будет! Заметь: сами разработчики xBSD не позиционируют свою систему как десктопную. Правда, существует такая штука как PC-BSD, делающая определенные шаги в десктопном направлении и, по слухам, устанавливающаяся из коробки, но «интеллектуальность» установщика до LINUX'а все-таки не дотягивает. И если LINUX сегодня легко ставят даже те, кто не имеет опыта вообще, то овладеть xBSD с лету не удастся!

В частности, FreeBSD 5.4 по умолчанию устанавливает уровень безопасности в 1 (даже если при установке ей открытым текстом сказать, что секьюрность идет в топку), делающий невозможным запуск X'ов (точнее Xorg) даже из-под root'а. Вываливается невразумительная жалоба на невозможность открытия /dev/io.

Приходится лезть в /etc/rc.conf и securelevel ручками, а для этого необходимо знать, как устанавливаются и конфигурируются X'ы. И новичок, впервые столкнувшийся с такой проблемой, просто не будет знать, откуда следует рыть. В общем, приятное времяпрепровождение гарантируется :). При этом ничто не мешает держать xBSD (вместе с другими необходимыми для работы системами) на виртуальной машине типа VM Ware, запускаемой откуда угодно — хоть из-под LINUX, хоть из-под Windows!

Другими словами, те, кому xBSD нужна для работы, вполне могут позволить себе раскошелиться на отдельную машину или запускать ее из-под эмулятора. Остальным же рекомендуется либо Windows, либо (при наличии совести и желания приобщиться к миру свободного ПО) — LINUX. Кстати, опыт работы с LINUX'ом не очень-то помогает общению с xBSD, поскольку многое в них реализовано неодинаково, в том числе и консоль.

Впрочем, справедливо и обратное. Монтирование дискеты под xBSD осуществляется утилитой mount_msdos (почему-то переименованной в последних версиях в mount_msdosfs), которой в LINUX просто нет, что вызывает удивление и страшно напрягает. Кстати, «типичный пользователь UNIX'а постоянно вспоминает, как называется команда print на этой неделе» (с). Цитате — 25 лет :).

выбор компонентов

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

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

Если позволяет дисковое пространство, лучше всего выбирать полную установку, а уже потом удалять ненужное.

разбивка диска

Дисковая подсистема — узкое место, и разбивка разделов во многом определяет производительность. Если есть возможность, стоит использовать SCSI-винчестеры, поскольку у них намного более мощный планировщик запросов, чем в IDE, в результате чего компиляция приложений занимает существенно меньше времени. Если же ты собираешься заниматься частой компиляцией, то оптимальным выбором окажется все-таки IDE с параллельным интерфейсом. SATA-контроллеры все еще достаточно сыроваты и содержат кучу ошибок, приводящих, в том числе, к потерям данных, причем потери могут быть весьма интересными. Так, некоторые контроллеры при определенных обстоятельствах теряют последние несколько байт в последнем секторе переданного блока, в результате чего файл записывается некорректно. Но если он занимает не весь кластер целиком, некоторое время ошибка остается незамеченной и проявляется только потом. Производители дешевых чипсетов с интегрированным SATA-контроллером (VIA. SiS) предпочитают исправлять такие ошибки в драйверах, естественно, выпущенных только для Windows и, возможно (хоть и маловероятно), для LINUX. Поэтому не бери SATA для xBSD, если полностью не уверен в безглючности.

Если виртуальной памяти не хватит, затребовавшее ее приложение просто завершится с ошибкой. Выделять же 512 x 2 == 1024 Мбайт памяти на подкачку совершенно нецелесообразно и необязательно! Потому что при разбивке по умолчанию swap-раздел располагается между корневым и всеми остальными разделами, а это значит, что головке диска придется совершать перемещения на более далекие дистанции, вызывающие ничем не оправданное снижение производительности.

Раздел /usr лучше всего размещать вплотную к корневому, а /swap, /var и /tmp — держать на отдельном диске. Причем /tmp должен идти после /var, а не наоборот. Мотив /var не требует большого пространства (100 Мбайт будет более, чем достаточно), а вот под временные файлы следует отвести побольше, можно даже весь оставшийся объем. Если расположить /var после /tmp'а, то головка диска будет сильно порхать, поскольку ей придется при каждом обращении /tmp <-> /var пересекать весь /tmp. Разумнее оптимизировать раскладку разделов. Тоже самое относится и к /swap, который лучше расположить в начале диска, выделив под него сколько-нибудь памяти. «Сколько-нибудь» — потому что очень трудно убедить установщик, что подкачка нам не нужна, и мы предпочитаем все данные хранить в оперативной памяти.

пересборка ядра

Все операционные системы семейства xBSD имеют монолитное ядро с опциональной поддержкой модулей, причем большая часть модулей может быть как включена непосредственно в само ядро, так и представлена динамически загружаемыми файлами. По умолчанию GENERIC-ядро включает в себя поддержку практически всего известного ему оборудования, в которое входят и SCSI-контроллеры, и сетевые карты, и другое оборудование, которое встречается только на серверах. Не говоря уже обо всех мыслимых и немыслимых сетевых протоколах, потребность в которых даже на серверах возникает далеко не всегда. Естественно, что это не проходит даром, и за поддержку приходится расплачиваться временем загрузки и потребляемой памятью. С другой стороны, динамические модули грузятся еще дольше. Поэтому наилучшей стратегией будет выбор такой конфигурации ядра, чтобы все часто используемые компоненты включались в него, а редко используемые — выносились в модули.

Управление ядром осуществляется путем прямого редактирования конфигурационных файлов GENETIC и LINT, расположенных в каталоге /sys/i386/conf, с последующей перекомпиляцией. Настроек, прямо или косвенно влияющих на производительность, очень много, поэтому ограничимся наиболее характерными.

А вот задействовать поддержку многопроцессорных машин (секция SMP Options) на многоядерных кристаллах однозначно стоит! С Hyper-Threading все намного сложение, и наперед очень трудно сказать, принесет ли оно увеличение производительности или нет. На некоторых приложениях наблюдается устойчивое замедление, некоторые не реагирует на это вообще. Так что все решает эксперимент.

Остальные опции относятся к такому типу оборудования, которого по умолчанию поддерживается слишком много, но далеко не все можно безболезненно убирать. В частности, «продергивая» список SCSI-устройств, нельзя забывать, что Zip на параллельном порту тоже относится к SCSI-устройствам (точнее, с помощью драйвера нижнего уровня, изображает из себя таковое), поэтому если отключить поддержку SCSI-устройств (как это делают многие пользователи, имеющие только IDE), ядро не сможет увидеть Zip и... Так и рождаются легенды о том, что xBSD не дружит с Zip'ом в принципе, и никаких драйверов для него нет.

Так же нельзя отключать поддержку ISA-шины, которая есть даже в тех компьютерах, в которых ее нет. В смысле, на физическом уровне нет (она не распаяна на плате), но куча устройств типа динамика или клавиатуры до сих пор «висят» на ISA-шине, эмулируемой южным мостом чипсета. Так что «оптимизировать» ядро следует с умом, обращая внимание на комментарии в мелочах и предварительно ознакомившись с архитектурой IBM PC в целом.

оптимизация

Увлекательное занятие, отнимающее кучу времени на компиляцию и многочисленные эксперименты. Ведь с первого раза собрать оптимально работающее ядро вряд ли получится. Зато потом... можно ускорить систему в несколько раз! А можно ничего не выиграть вообще. Это уж от оптимизатора и мощности оборудования зависит. Тут главное — не перестараться и не потратить на оптимизацию больше времени, чем она в принципе способна отдать назад. Тем более не стоит ковырять стабильно работающую ось, если в этом нет жизненно важной необходимости. Как говорили древние: «Не лови рыбу на золотой крючок» :). Если он оборвется, никакой улов не компенсирует потери.