Chapter 13. Разное

Это только кажется, что для FreeBSD требуется больше места на разделе подкачки, чем для Linux. На самом деле это не так. Главное отличие FreeBSD от Linux в этом плане заключается в том, что FreeBSD активно перемещает неиспользуемые страницы памяти, к которым не было обращений, в раздел подкачки, чтобы увеличить объём доступной физической памяти для активного использования. Linux же перемещает страницы памяти в раздел подкачки только в крайнем случае. Получаемое во FreeBSD увеличение нагрузки на раздел подкачки компенсируется более эффективным использованием оперативной памяти.

Заметьте, что, хотя FreeBSD предпочитает использовать раздел подкачки, она не может сбросить все неактивные страницы в своп при полностью неактивной системе. Так что вряд ли может возникнуть ситуация, когда, проснувшись рано утром, вы обнаружите, что вся ваша система находится в разделе подкачки, хотя она простаивала всю ночь.

Просто дело в том, что под свободной памятью подразумевается никак не используемая память. Вся память, которая вашей программе явно не выделялась, используется ядром FreeBSD для дискового кэша. Значения, показываемые утилитой top(1), помеченные как Inact, Cache и Buf - это всё кэшированные данные разных степеней устаревания. То, что данные находятся в кэше, означает, что система не будет обращаться к медленному диску снова за теми данными, обращение к которым было недавно, повышая таким образом общую производительность. В общем случае маленькие значения в пункте Free, показываемые утилитой top(1) для свободной памяти - это хорошо, если, конечно они не очень маленькие.

Для понимания того, почему FreeBSD использует формат ELF, вы должны сначала получить представление о трёх "доминирующих" форматах выполнимых файлов для Unix:

• a.out(5)

  Это самый старый, "классический" формат объектных файлов для Unix. В нём используется короткий и компактный заголовок с магическим числом в начале, которое часто используется для определения формата (за подробным описанием обратитесь к странице Справочника о a.out(5)). Он содержит три загружаемых сегмента: .text, .data и .bss плюс таблицу символов и таблицу строк.

• COFF

  Это формат объектных файлов SVR3. Дополнительно в заголовок включена таблица секций, так что вы можете иметь их больше, чем только .text, .data и .bss.

• ELF

  Преемник COFF, в который добавлены возможности иметь много секций и 32- или 64-разрядные значения. Один большой минус: ELF был спроектирован также в предположении, что для каждой аппаратной платформы будет существовать только один ABI. Это предположение достаточно некорректно, и даже в мире коммерческих реализаций SYSV (в котором имеется по крайней мере три ABI: SVR4, Solaris и SCO) это не так.

  FreeBSD каким-то образом пытается решить эту проблему, предоставляя утилиту для пометки конкретного выполнимого файла ELF с информацией о ABI, с которым он совместим. Обратитесь к странице Справочника об утилите brandelf(1) за подробной информацией.

FreeBSD выросла на "классических" традициях и традиционно использовала формат a.out(5), технологию, опробованную и проверенную во многих вариациях BSD. Хотя давно уже можно было компилировать и выполнять родные выполнимые файлы (и ядро) в формате ELF, FreeBSD с самого начала сопротивлялась переходу на ELF как на формат, используемый по умолчанию. Почему? Когда мир Linux делал болезненный переход к ELF, причин отвергнуть формат a.out было не так уж и много, разве что их негибкий механизм работы с совместно используемыми библиотеками, который был основан на таблице переходов, что делало построение таких библиотек очень затруднительным для разработчиков. Так как средства работы с ELF предоставляли решение этой проблемы и это было в общем-то "шагом вперёд" в любом случае, цена перехода была признана стоящей того и переход был сделан.

В случае FreeBSD, наш механизм работы с совместно используемыми библиотеками очень похож на механизм, применяемый в SunOS, поэтому его очень легко использовать. Однако, начиная с 3.0, FreeBSD официально поддерживает ELF как формат, используемый по умолчанию. И, хотя формат a.out поддерживается в полной мере, разработчики из проекта GNU, являющиеся авторами компилятора, который мы используем, больше не поддерживают формат a.out. Это заставило нас поддерживать различные версии компилятора и компоновщика, и не позволило воспользоваться всеми возможностями последних разработок GNU. Потребность в наличии реализации ISO-C++, в основном конструкторов и деструкторов, также привела к поддержке ELF в будущих релизах FreeBSD.

Если вернуться в далёкое тёмное прошлое, то тогда компьютеры были очень просто устроены. На них могла работать простая, маленькая система. Формат a.out полностью решал задачу представления программ на простых системах (PDP-11). Когда же люди перенесли Unix с простых систем, они оставили a.out, так как его было достаточно для ранних реализаций Unix для таких архитектур, как Motorola 68k, VAX, и тд.

Затем какой-то умный инженер решил, что если он может заставить программное обеспечение делать некоторые тонкие манипуляции, то это позволит преодолеть некоторые ограничения при проектировании и позволит ядру процессора работать быстрее. Когда это было сделано с новым типом аппаратуры (в наши дни известном как RISC), оказалось, что a.out плохо подходит для этой аппаратуры, поэтому было разработано много новых форматов для достижения большей производительности от такого аппаратного обеспечения, чем может дать простой, имеющий ограничения формат a.out. Были разработаны такие форматы, как COFF, ECOFF и ещё несколько безвестных других со своими ограничениями, пока наконец все не остановились на формате ELF.

Вдобавок к этому, так как размеры программ стали достигать огромных размеров, а дисковая (и физическая) память оставалась сравнительно небольшой, то возникла концепция совместно используемых библиотек. Система VM также стала более мощной. Хотя каждое из этих нововведений продолжало использовать формат a.out, его бесполезность становилась видна всё больше и больше с добавлением каждой новой возможности. К тому же люди захотели динамически загружать код во время выполнения программ или сбрасывать части программ после выполнения кода инициализации для экономии основной памяти и/или размера свопа. Языки программирования становились всё более умными и люди захотели автоматического запуска некоторого кода перед главной процедурой программы. С форматом a.out была сделана масса ухищрений для реализации всех этих требований, и они в общем-то работали. В конце концов наступил момент, когда формат a.out перестал бы справляться со всеми этими проблемами без ещё больших потерь в коде и гибкости в работе. Тогда как ELF решал многие из этих проблем, переход на него был бы болезненным на рабочей системе. Так что ELF ждал момента, когда был бы более болезненным оставаться с форматом a.out, чем перейти к формату ELF.

Однако с течением времени инструменты разработки, на которых основаны инструменты разработки FreeBSD (особенно ассемблер и загрузчик), разделились на две параллельные ветви. В дерево FreeBSD была добавлена поддержка совместно используемых библиотеки и были исправлены некоторые ошибки. Разработчики из GNU, которые изначально писали эти программы, полностью их переделали, добавив более простую поддержку построения кросс-компиляторов, в котором можно использовать различные форматы, и тд. Когда многие захотели строить кросс-компилятор с выходным кодом для FreeBSD, то им не повезло, так как старые исходные тексты, которые FreeBSD использовала для as и ld, не подошли. Новый набор утилит от GNU (binutils) поддерживает кросс-компиляцию, ELF, совместно используемые библиотеки, расширения C++, и тд. Вдобавок, многие разработчики выпускают программы в бинарном формате ELF, и для FreeBSD было бы полезно иметь возможность их запускать. И если такая возможность будет реализована, зачем тогда вообще продолжать опираться на a.out? Это измученная старая лошадь, которая была полезна долгое время, но сейчас самое время от неё отказаться, оставив в прошлом долгие годы преданной службы.

ELF более выразителен, чем a.out, и позволяет реализовать большую расширяемость основной системы. Инструменты для работы с ELF лучше поддерживаются разработчиками, и предоставляют поддержку кросс-компиляции, что для многих важно. ELF может работать немного медленнее, чем a.out, но это трудно измерить. Также между ними есть некоторые отличия по распределению страниц памяти, обработке кода инициализации, и тд. Никакие из этих отличий особо не важны, но эти отличия всё же есть. Со временем поддержка a.out будет убрана из ядра GENERIC, и постепенно убрана из системы совсем, как только отпадёт нужда в запуске старых программ в формате a.out.

Символические ссылки не имеют прав доступа, а по умолчанию утилита chmod(1) не следует символической ссылке для изменения прав доступа к файлу, на который указывает ссылка. Поэтому, если у вас есть файл, скажем, с именем foo и символическая ссылка bar на этот файл, то эта команда всегда будет выполняться успешно.

    % chmod g-w bar
     

Однако права на файл foo не изменятся.

Чтобы это работало, используйте опции -H или -L вместе с опцией -R. Обратитесь к страницам Справочника по команде chmod(1) и по symlink(7).

Наверное, вы думаете, что достаточно будет изменить значение константы UT_NAMESIZE, перекомпилировать полностью систему и всё будет работать. К несчастью, часть приложений и утилит (включая системные) имеют жёстко заданные малые значения (не всегда 8 или 9, но и такие странные, как 15 или 20) в структурах и буферах. Это приведёт не только к порче файлов журналов (из-за записи полей переменного размера там, где ожидается поле фиксированного размера), но может повлиять на работу клиентов системы Sun NIS и может в принципе вызвать другие проблемы при взаимодействии с другими системами Unix.

Во FreeBSD 3.0 и старше, максимальная длина имени была увеличена до 16 символов и все утилиты с предопределённым размером имени были найдены и исправлены. Так как это касается столь многих областей в системе, то такие изменения не делались вплоть до 3.0.

Если вы абсолютно уверены, что сможете найти и исправить проблемы такого рода самостоятельно, когда они возникнут, то можете увеличить длину регистрационного имени в ранних релизах, отредактировав файл /usr/include/utmp.h и изменив соответствующим образом константу UT_NAMESIZE. Вы должны будете также изменить значение MAXLOGNAME в файле /usr/include/sys/param.h, чтобы оно соответствовало UT_NAMESIZE. И наконец, если вы компилируете из исходных текстов, не забудьте, что /usr/include обновляется каждый раз! Делайте изменения в соответствующих файлах каталога /usr/src/..

Да, начиная с версии 3.0, вы можете использовать эмулятор DOS doscmd от BSDI, который был интегрирован в систему и усовершенствован. Пошлите письмо Список рассылки, посвященный эмуляции в FreeBSD <freebsd-emulation@FreeBSD.org>, если вы заинтересованы в участии в этом проекте.

Для систем, предшествующих 3.0, в коллекции портов есть замечательная утилита pcemu, эмулирующая процессор 8088 и функции BIOS, чего достаточно для запуска приложений DOS, работающих в текстовом режиме. Она требует X Window System (которая поставляется как XFree86).

Ознакомтесь с Часто Задаваемыми Вопросами по Переводам в FreeBSD Documentation Project Primer.

Хотя FreeBSD не предоставляет бесплатный доступ ни к одному из своих серверов, другие компании предоставляют Unix-системы с открытым доступом. Стоимость этой услуги различна, также как и ограниченный набор услуг.

Arbornet, Inc, также известный как M-Net, предоставляет свободный доступ к Unix-системам с 1983. Начиная на платформе Altos с работающей System III, сайт перешел на BSD/OS в 1991. В июне 2000 сайт сменил систему снова, теперь на FreeBSD. M-Net может быть доступна через протоколы telnet и SSH и предоставляет доступ к полному набору программного обеспечения FreeBSD. Однако доступ к сети ограничен для членов и спонсоров, которые поддерживают систему, которая работает как неприбыльная организация. M-Net предоставляет также услуги электронной доски объявлений (BBS) и интерактивного чата.

Grex представляет собой сайт, очень похожий на M-Net, включая то же самое программное обеспечение для электронной доски объявлений (BBS) и интерактивного чата. Однако платформой является Sun 4M под управлением SunOS

Сокращение SUP означает Software Update Protocol, который был разработан в CMU для синхронизации исходных текстов. Мы используем его для синхронизации исходных текстов на удалённых сайтах с основным сервером разработчиков.

Протокол SUP использует пропускную способность канала неэффективно, и был отвергнут. В настоящее время рекомендуемым методом для синхронизации исходных текстов является протокол CVSup.

У него нет определенного имени, он называется просто "даемон BSD". Если вам непременно нужно имя, называйте его "beastie". Заметьте, что "beastie" произносится как "BSD".

Больше о даемоне BSD вы можете узнать из его домашней страницы.

Вполне. Права на даемона BSD имеет Marshall Kirk McKusick. Для выяснения подробностей относительно правил его использования вы можете обратиться к странице автора Statement on the Use of the BSD Daemon Figure.

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

В каталоге /usr/share/examples/BSD_daemon/ есть рисунки в форматах eps и Xfig.

В. Кто-нибудь делал замеры температуры при работе FreeBSD? Я знаю, что Linux греется меньше, чем DOS, но никогда не видел упоминания FreeBSD. Наверное, он сильно греется.

О. Нет, но мы сделали различные вкусовые тесты у добровольцев с завязанными глазами, которые до этого приняли по 250 микрограмм LSD-25. 35% добровольцев заявило, что FreeBSD имеет вкус апельсина, тогда как вкус Linux расценивался как фиолетовый туман. Ни одна из групп не отметила значительной разницы в температуре. Мы хотели опубликовать полные результаты этого опроса, когда обнаружили, что слишком много добровольцев покинули помещение во время тестов, что несколько смазало результаты. Думаем, что большинство из них работают сейчас в Apple над их новым GUI "чеши и нюхай". Это старый добрый бизнес!

Серьёзно, и FreeBSD, и Linux используют инструкцию HLT (halt), когда система простаивает, что уменьшает потребление энергии и в свою очередь, выделение тепла. Вдобавок, если у вас настроен APM (комплексное управление энергопотреблением), то FreeBSD может переводить процессор в режим пониженного энергопотребления.

В. Делает ли FreeBSD что-нибудь "эдакое" при компиляции ядра, что вызывает поскрипывание микросхем памяти? При компиляции (и в короткий промежуток времени после обнаружения дисковода при старте системы) от микросхем памяти исходит странный царапающий звук.

О. Да! Вы, наверное, видели частое упоминание "даемонов" в документации по BSD, но не многие знают, что это настоящие нематериальные существа, которые теперь завладели вашим компьютером. Царапающий звук, издаваемый микросхемами памяти - это на самом деле высокочастотное перешёптывание между даемонами, когда они решают, как лучше справиться с различными задачами по администрированию системы.

Если шум достиг ваших ушей, команда DOS fdisk /mbr их спугнёт, но не удивляйтесь, если они отреагируют соответствующим образом и попытаются вас остановить. Фактически, если во время выполнения этой команды вы услышите сатанинский голос Билла Гейтса из встроенного динамика, бегите и даже не оглядывайтесь! Избавленные от противостояния с даемонами BSD, близнецы-демоны DOS и Windows часто могут захватить полный контроль не только над вашей машиной и навлечь вечное проклятие на вашу душу. Теперь, когда вы это знаете, если бы у вас был выбор, думаем, что вы бы предпочли слышать царапающий звук, не так ли?

MFC - это сокращение от "Merged From -CURRENT". Оно используется в протоколах изменений CVS для отметки того, что изменение было перенесено в ветвь STABLE из CURRENT.

Это сокращение значит что-то на секретном языке, который могут знать только посвящённые. Это нельзя перевести один к одному, однако достаточно сказать, что перевод с BSD - это что-то между "Команда Formula-1", "Пингвины - это вкусные плюшки" и "Мы прикольнее, чем Linux". :-)

Если серьёзно, то BSD является сокращением от "Berkeley Software Distribution", названия, которое было выбрано Berkeley CSRG (Computer Systems Research Group) для их дистрибутива Unix.

repo-copy (что является краткой формой от "repository copy") обозначает прямое копирование файлов внутри репозитория CVS.

Без repo-copy, если есть необходимость скопировать или переместить файл в другое место репозитория, то коммиттер должен выполнять команды cvs add для помещения файла на новое место, а затем cvs rm, чтобы удалить старый файл, если старая копия должна быть удалена.

Минусом этого метода является то, что история (то есть записи в журналах CVS) работы с файлом не копируются в новое место. Так как Проект FreeBSD осознаёт важность сохранения истории, вместо описанного процесса зачастую используется копирование в репозитории. Это действие заключается в том, что один из хозяев репозитория копирует файлы непосредственно внутри репозитория, не пользуясь командами cvs(1).

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

Более пространный и полный ответ заключается в том, что после очень долгого обсуждения того, должна ли утилита sleep(1) обрабатывать дробное число, заданное в качестве второго аргумента, Poul-Henning Kamp <phk@FreeBSD.org> опубликовал большое сообщение, озаглавленное " Велосипедная фара (любого цвета) на зелёной траве...". Соответствующие части этого сообщения цитируются ниже.

	"Что там насчёт этой велосипедной фары?" Кто-то из вас меня спрашивал. Это долгая история, или же это старая история, но на самом деле она коротка. В начале 1960-х годов Паркинсон (C. Northcote Parkinson) написал книгу "Закон Паркинсона", которая содержит много интересных взглядов на процесс управления. [немного выдержек из краткого содержания книги] В конкретном примере с велосипедной фарой другим важным объектом является атомная электростанция. Я полагаю, что это иллюстрирует древность книги. Паркинсон показал, что вы можете прийти на совещание руководителей и получить добро на строительство многомиллионной или даже многомиллиардной атомной электростанции, но если вы хотите получить финансирование производства велосипедных фар, то погрязнете в бесконечных обсуждениях. Паркинсон объясняет это тем, что атомная станция настолько большой, дорогой и сложный объект, что люди не могут его осознать и вместо того, чтобы попробовать это сделать, они полагаются на то, что кто-то уже проверил все мелочи до того, как всё зашло так далеко. В своей книге Ричард П. Фейнманн (Richard P. Feynmann) даёт несколько интересных и очень поучительных примеров, связанных с Лос Аламос. Велосипедная фара - это противоположный случай. Любой может сделать фару за один уикэнд, и у него ещё останется время посмотреть футбол по телевизору. Так что не важно, насколько хорошо вы готовились к обсуждению, насколько убедительны будут ваши аргументы, кто-нибудь воспользуется шансом показать, что он не зря ест свой хлеб, что он обращает внимание, что он здесь. В Дании это называется "оставить отпечаток своего пальца". Это касается личной гордости и престижа, это похоже на возможность указать куда-то и сказать: " Вон там! Это сделал я." Это сильно выражено в политиках, но присутствует во многих людях, которые получают возможность сделать это. Просто вспомните об отпечатках ног во влажном цементе.
--Poul-Henning Kamp <phk@FreeBSD.org> on freebsd-hackers, October 2, 1999

Необходимо иметь ровно одну тысячу сто семьдесят два разработчика:

Двадцать три сообщат в -CURRENT о том, что не горит свет;

Четыре начнут утверждать, что это проблема конфигурации и такие сообщения нужно посылать в -questions;

Трое оформят PR по этому поводу, причём одно их них будет направлено в doc и будет содержать только строчку "здесь темно";

Один закоммитит неоттестированную лампочку, что сломает построение системы, а затем через пять минут вернёт всё назад;

Восемь поругаются с авторами PR по поводу включения патчей в PR;

Пять сообщат о том, что не проходит компиляция системы;

Тридцать один человек ответит, что у них всё работает и наверное, те выполняли cvsup в неподходящее время;

Один пошлёт патч для новой лампочки в -hackers;

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

Тридцать семь начнут кричать, что лампочки не относятся к базовой системе, что коммиттеры не имеют права делать такие вещи без опроса общественности и ЧТО ВООБЩЕ -CORE ДЕЛАЕТ ПО ЭТОМУ ПОВОДУ?

Две сотни напишут о цвете велосипедных фар;

Трое скажут, что этот патч не соответствует style(9)

Семнадцать возразят, что предлагаемая новая лампа подпадает под лицензию GPL;

Пятьсот восемьдесят шесть раздуют флейм по поводу сравнения лицензий GPL, BSD, MIT, NPL и личных мнений о неизвестных основателей FSF;

Семеро пошлют различные части этих обсуждений в -chat и -advocacy;

Один закоммитит предлагаемую лампу, хотя она светит хуже, чем старая;

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

Сорок шесть громко воспротивятся этому изменению и потребуют объяснений от -core;

Одиннадцать попросят уменьшить размер лампочки, чтобы она подошла к их Тамагочи на случай, если мы когда-нибудь соберёмся переносить FreeBSD на эту платформу;

Семьдесят три заявят о SNR в -hackers и -chat и в знак протеста отпишутся;

Тринадцать пошлют письма "unsubscribe", "How do I unsubscribe?", и "Please remove me from the list" с обычной подписью;

Один закоммитит работающую лампочку в то время, как все будут слишком заняты руганью, чтобы это заметить;

Тридцать один человек напишет, что новая лампочка будет светить на 0.364% ярче, если её откомпилировать с помощью TenDRA (хотя при этом она приобретёт форму куба) и что FreeBSD должна перейти на компилятор TenDRA, а не на EGCS;

Один заметит, что у лампочки отсутствует цоколь;

Девять (включая авторов PR) спросят "что такое MFC?";

Спустя две недели после смены лампочки пятьдесят семь человек сообщат о том, что света всё равно нет.

Nik Clayton <nik@FreeBSD.org> добавил:

Я сильно смеялся над всем этим.

И тогда я подумал, "Постойте-ка, найдётся ли кто-нибудь, чтобы задокументировать это где-нибудь?"

И на меня снизошло озарение :-)

Они отправляются в специальную сточную трубу для данных в CPU, где пробразуются в тепло, выдуваемое через охлаждающие вентиляторы. Вот почему охлаждение ЦП становится все более важным; так как люди используют все более быстрые процессоры, они все менее заботятся о данных, все большее их количество оканчивает свой путь в /dev/null, перегревая ЦП. Если вы удалите /dev/null (что соответственно отключит трубу данных в ЦП), то ваш процессор может охладиться, но система начнет переполняться излишними данными и начнет работать с ошибками. Если у вас быстрое сетевое подключение, вы можете охладить CPU, читая данные из /dev/random и посылая их куда-нибудь; однако вы рискуете перегреть ваше сетевое соединение и / или разозлить вашего провайдера, так как большинство данных преобразуется в тепло на его оборудовании, но, как правило, у него хорошее охлаждение, так что если вы не перестараетесь, все должно быть в порядке.

Пол Робинсон (Paul Robinson) добавляет:

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

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

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