Chapter 16. Разное

16.1. Почему FreeBSD использует гораздо больше места в разделе подкачки, чем Linux?
16.2. Почему утилита top(1) показывает очень маленький объём свободной памяти, даже когда запущено всего лишь несколько приложений?
16.3. Почему используются (и что из себя представляют) форматы выполнимых файлов a.aut и ELF?
16.4. Да, но почему так много разных форматов?
16.5. Почему командой chmod невозможно изменить права на символические ссылки?
16.6. Почему длина регистрационного имени во FreeBSD 2.2.X и более ранних версий не должна превышать 8 символов?
16.7. Можно ли запускать программы для DOS во FreeBSD?
16.8. Что мне нужно сделать чтобы перевести документацию FreeBSD на мой родной язык?.
16.9. Где можно получить бесплатный доступ к FreeBSD?
16.10. Что такое sup и как это можно использовать?
16.11. Как зовут этого маленького симпатичного красного парня?
16.12. Могу ли я использовать изображение даемона BSD?
16.13. Не найдется ли у вас изображений даемона BSD, которые можно использовать?
16.14. Что такое MFC?
16.15. Что означает сокращение BSD?
16.16. Что такое repo-copy?
16.17. Почему я должен беспокоиться о цвете фар велосипеда?

16.1. Почему FreeBSD использует гораздо больше места в разделе подкачки, чем Linux?

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

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

16.2. Почему утилита top(1) показывает очень маленький объём свободной памяти, даже когда запущено всего лишь несколько приложений?

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

16.3. Почему используются (и что из себя представляют) форматы выполнимых файлов a.aut и ELF?

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

Note: До FreeBSD версии 3.x, во FreeBSD использовался формат a.out.

  • 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.

16.4. Да, но почему так много разных форматов?

Если вернуться в далёкое тёмное прошлое, то тогда компьютеры были очень просто устроены. На них могла работать простая, маленькая система. Формат 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.

16.5. Почему командой chmod невозможно изменить права на символические ссылки?

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

    % chmod g-w bar

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

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

WarningОпция -R выполняет команду chmod(1) РЕКУРСИВНО. Будьте осторожны, задавая каталоги или символические ссылки на каталоги в параметрах chmod(1). Если вы хотите изменить права на каталог, на который указывает символическая ссылка, используйте chmod(1) без опций и следуйте символической ссылке с помощью лидирующего слэша (/). Например, если foo является символической ссылкой на каталог bar, а вы хотите изменить права на foo (на самом деле bar), вы должны выполнить команду типа следующей:

    % chmod 555 foo/

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

16.6. Почему длина регистрационного имени во FreeBSD 2.2.X и более ранних версий не должна превышать 8 символов?

Наверное, вы думаете, что достаточно будет изменить значение константы 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/..

16.7. Можно ли запускать программы для DOS во FreeBSD?

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

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

16.8. Что мне нужно сделать чтобы перевести документацию FreeBSD на мой родной язык?.

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

16.9. Где можно получить бесплатный доступ к FreeBSD?

Хотя 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

16.10. Что такое sup и как это можно использовать?

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

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

16.11. Как зовут этого маленького симпатичного красного парня?

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

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

16.12. Могу ли я использовать изображение даемона BSD?

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

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

16.13. Не найдется ли у вас изображений даемона BSD, которые можно использовать?

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

16.14. Что такое MFC?

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

16.15. Что означает сокращение BSD?

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

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

16.16. Что такое repo-copy?

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

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

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

16.17. Почему я должен беспокоиться о цвете фар велосипеда?

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

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

 

"Что там насчёт этой велосипедной фары?" Кто-то из вас меня спрашивал.

Это долгая история, или же это старая история, но на самом деле она коротка. В начале 1960-х годов Паркинсон (C. Northcote Parkinson) написал книгу "Закон Паркинсона", которая содержит много интересных взглядов на процесс управления.

[немного выдержек из краткого содержания книги]

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

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

Паркинсон объясняет это тем, что атомная станция настолько большой, дорогой и сложный объект, что люди не могут его осознать и вместо того, чтобы попробовать это сделать, они полагаются на то, что кто-то уже проверил все мелочи до того, как всё зашло так далеко. В своей книге Ричард П. Фейнманн (Richard P. Feynmann) даёт несколько интересных и очень поучительных примеров, связанных с Лос Аламос.

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

В Дании это называется "оставить отпечаток своего пальца". Это касается личной гордости и престижа, это похоже на возможность указать куда-то и сказать: " Вон там! Это сделал я." Это сильно выражено в политиках, но присутствует во многих людях, которые получают возможность сделать это. Просто вспомните об отпечатках ног во влажном цементе.

 
--Poul-Henning Kamp on freebsd-hackers, October 2, 1999