f6a467bdbd
hackers.sgml 1.15 hardware.sgml 1.16 misc.sgml 1.15 network.sgml 1.22 preface.sgml 1.31 commercial.sgml 1.4 x.sgml 1.7 PR: 11001, 11002, 11025, 11026, 11027, 11042, 11043 Submitted by: Andrey Zakhvatov <andy@icc.surw.chel.su>
338 lines
18 KiB
Text
338 lines
18 KiB
Text
<!-- $Id: misc.sgml,v 1.4 1999-04-13 20:00:29 dt Exp $ -->
|
||
<!-- The FreeBSD Russian Documentation Project -->
|
||
|
||
<sect>
|
||
<heading>Разное<label id="misc"></heading>
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему FreeBSD использует гораздо больше места в разделе подкачки, чем
|
||
Linux?
|
||
</heading>
|
||
|
||
<p>Это только кажется, что для FreeBSD требуется больше места на разделе
|
||
подкачки, чем для Linux. На самом деле это не так. Главное отличие
|
||
FreeBSD от Linux в этом плане заключается в том, что FreeBSD активно
|
||
перемещает неиспользуемые страницы памяти, к которым не было обращений,
|
||
в раздел подкачки, чтобы увеличить объём доступной физической памяти
|
||
для активного использования. Linux же перемещает страницы памяти в
|
||
раздел подкачки только в крайнем случае. Получаемое во FreeBSD
|
||
увеличение нагрузки на раздел подкачки компенсируется более эффективным
|
||
использованием оперативной памяти.
|
||
|
||
<p>Заметьте, что, хотя FreeBSD предпочитает использовать раздел подкачки,
|
||
она не может сбросить все неактивные страницы в своп при полностью
|
||
неактивной системе. Так что вряд ли может возникнуть ситуация, когда,
|
||
проснувшись рано утром, вы обнаружите, что вся ваша система находится в
|
||
разделе подкачки, хотя она простаивала всю ночь.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему используются (и что из себя представляют) форматы выполнимых
|
||
файлов a.aut и ELF?
|
||
</heading>
|
||
|
||
<p>Для понимания того, почему FreeBSD использует формат <tt>a.out</tt>,
|
||
вы должны сначала получить представление о трёх "основных" форматах
|
||
выполнимых файлов для UNIX:
|
||
|
||
<itemize>
|
||
<item><htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
|
||
name="a.out">
|
||
|
||
<p>Это самый старый, `классический' формат объектных файлов для UNIX.
|
||
В нём используется короткий и компактный заголовок с магическим числом
|
||
в начале, которое часто используется для определения формата
|
||
(за подробным описанием обратитесь к странице Справочника о <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?a.out(5)" name="a.out(5)">).
|
||
Он содержит три загружаемых сегмента: .text, .data и .bss плюс
|
||
таблицу символов и таблицу строк.
|
||
|
||
<item><bf>COFF</bf>
|
||
<p>Это формат объектных файлов SVR3. Дополнительно в заголовок
|
||
включена таблица секций, так что вы можете иметь их больше, чем только
|
||
.text, .data и .bss.</item>
|
||
|
||
<item><bf>ELF</bf>
|
||
<p>Преемник <tt/COFF/, в который добавлены возможности иметь много
|
||
секций и 32- или 64-разрядные значения. Один большой минус:
|
||
<tt/ELF/ был спроектирован также в предположении, что для каждой
|
||
аппаратной платформы будет существовать только один ABI. Это
|
||
предположение достаточно некорректно, и даже в мире коммерческих
|
||
реализаций SYSV (в котором имеется по крайней мере три ABI: SVR4,
|
||
Solaris и SCO) это не так.
|
||
|
||
<p>FreeBSD каким-то образом пытается решить эту проблему, предоставляя
|
||
утилиту для <em>пометки</em> конкретного выполнимого файла <tt/ELF/
|
||
с информацией о ABI, с которым он совместим. Обратитесь к странице
|
||
Справочника об утилите <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?brandelf" name="brandelf">
|
||
за подробной информацией.
|
||
</itemize>
|
||
|
||
<p>FreeBSD выросла на "классических" традициях и традиционно использовала
|
||
формат <htmlurl url="http://www.freebsd.org/cgi/man.cgi?a.out(5)"
|
||
name="a.out">, технологию, опробованную и проверенную во многих
|
||
вариациях BSD. Хотя давно уже можно было компилировать и выполнять
|
||
родные выполнимые файлы (и ядро) в формате <tt/ELF/, FreeBSD с самого
|
||
начала сопротивлялась переходу на <tt/ELF/ как на формат, используемый
|
||
по умолчанию. Почему? Когда мир Linux делал болезненный переход к
|
||
<tt/ELF/, причин отвергнуть формат <tt/a.out/ было не так уж и много,
|
||
разве что их негибкий механизм работы с совместно используемыми
|
||
библиотеками, который был основан на таблице переходов, что делало
|
||
построение таких библиотек очень затруднительным для разработчиков.
|
||
Так как средства работы с <tt/ELF/ предоставляли решение этой проблемы
|
||
и это было в общем-то "шагом вперёд" в любом случае, цена перехода была
|
||
признана стоящей того и переход был сделан.
|
||
|
||
<p>В случае FreeBSD, наш механизм работы с совместно используемыми
|
||
библиотеками очень похож на механизм, применяемый в <tt>SunOS</tt>,
|
||
поэтому его очень легко использовать. Однако, начиная с 3.0, FreeBSD
|
||
официально поддерживает <tt/ELF/ как формат, используемый по умолчанию.
|
||
И, хотя формат <tt/a.out/ поддерживается в полной мере, разработчики
|
||
из проекта GNU, являющиеся авторами компилятора, который мы используем,
|
||
больше не поддерживают формат <tt/a.out/. Это заставило нас поддерживать
|
||
различные версии компилятора и компоновщика, и не позволило
|
||
воспользоваться всеми возможностями последних разработок GNU.
|
||
Потребность в наличии реализации ISO-C++, в основном конструкторов и
|
||
деструкторов, также привела к поддержке <tt/ELF/ в будущих релизах
|
||
FreeBSD.
|
||
|
||
<sect1>
|
||
<heading>Да, но почему так много разных форматов?</heading>
|
||
|
||
<p>Если вернуться в далёкое тёмное прошлое, то тогда компьютеры были
|
||
очень просто устроены. На них могла работать простая, маленькая
|
||
система. Формат a.out полностью решал задачу представления программ
|
||
на простых системах (PDP-11). Когда же люди перенесли unix с простых
|
||
систем, они оставили a.out, так как его было достаточно для ранних
|
||
реализаций unix для таких архитектур, как Motorola 68k, VAX, итд.
|
||
|
||
<p>Затем какой-то умный инженер решил, что если он может заставить
|
||
программное обеспечение делать некоторые тонкие манипуляции, то это
|
||
позволит преодолеть некоторые ограничения при проектировании и позволит
|
||
ядру процессора работать быстрее. Когда это было сделано с новым типом
|
||
аппаратуры (в наши дни известном как RISC), оказалось, что <tt/a.out/
|
||
плохо подходит для этой аппаратуры, поэтому было разработано много новых
|
||
форматов для достижения большей производительности от такого аппаратного
|
||
обеспечения, чем может дать простой, имеющий ограничения формат
|
||
<tt/a.out/. Были разработаны такие форматы, как <tt/COFF/, <tt/ECOFF/ и
|
||
ещё несколько безвестных других со своими ограничениями, пока наконец
|
||
все не остановились на формате <tt/ELF/.
|
||
|
||
<p>Вдобавок к этому, так как размеры программ стали достигать огромных
|
||
размеров, а дисковая (и физическая) память оставалась сравнительно
|
||
небольшой, то возникла концепция совместно используемых библиотек.
|
||
Система VM также стала более мощной. Хотя каждое из этих нововведений
|
||
продолжало использовать формат <tt/a.out/, его бесполезность становилась
|
||
видна всё больше и больше с добавлением каждой новой возможности. К тому
|
||
же люди захотели динамически загружать код во время выполнения программ
|
||
или сбрасывать части программ после выполнения кода инициализации для
|
||
экономии основной памяти и/или размера свопа. Языки программирования
|
||
становились всё более умными и люди захотели автоматического запуска
|
||
некоторого кода перед главной процедурой программы. С форматом
|
||
<tt/a.out/ была сделана масса ухищрений для реализации всех этих
|
||
требований, и они в общем-то работали. В конце концов наступил момент,
|
||
когда формат <tt/a.out/ перестал бы справляться со всеми этими
|
||
проблемами без ещё больших потерь в коде и гибкости в работе. Тогда
|
||
как <tt/ELF/ решал многие из этих проблем, переход на него был бы
|
||
болезненным на рабочей системе. Так что <tt/ELF/ ждал момента, когда
|
||
был бы более болезненным оставаться с форматом <tt/a.out/, чем перейти
|
||
к формату <tt/ELF/.
|
||
|
||
<p>Однако с течением времени инструменты разработки, на которых
|
||
основаны инструменты разработки FreeBSD (особенно ассемблер и
|
||
загрузчик), разделились на две параллельные ветви. В дерево FreeBSD
|
||
была добавлена поддержка совместно используемых библиотеки и были
|
||
исправлены некоторые ошибки. Разработчики из GNU, которые изначально
|
||
писали эти программы, полностью их переделали, добавив более простую
|
||
поддержку построения кросс-компиляторов, в котором можно использовать
|
||
различные форматы, итд. Когда многие захотели строить кросс-компилятор
|
||
с выходнвм кодом для FreeBSD, то им не повезло, так как старые исходные
|
||
тексты, которые FreeBSD использовала для as и ld, не подошли. Новый
|
||
набор утилит от GNU (binutils) поддерживает кросс-компиляцию, <tt/ELF/,
|
||
совместно используемые библиотеки, расширения C++, итд. Вдобавок,
|
||
многие разработчики выпускают программы в бинарном формате <tt/ELF/, и
|
||
для FreeBSD было бы полезно иметь возможность их запускать. И если
|
||
такая возможность будет реализована, зачем тогда вообще продолжать
|
||
опираться на <tt/a.out/? Это измученная старая лошадь, которая была
|
||
полезна долгое время, но сейчас самое время от неё отказаться, оставив
|
||
в прошлом долгие годы преданной службы.
|
||
|
||
<p><tt/ELF/ более выразителен, чем a.out, и позволяет реализовать
|
||
большую расширяемость основной системы. Инструменты для работы с
|
||
<tt/ELF/ лучше поддерживаются разработчиками, и предоставляют поддержку
|
||
кросс-компиляции, что для многих важно. <tt/ELF/ может работать немного
|
||
медленнее, чем a.out, но это трудно измерить. Также между ними есть
|
||
некоторые отличия по распределению страниц памяти, обработке кода
|
||
инициализации, итд. Никакие из этих отличий особо не важны, но эти
|
||
отличия всё же есть. Со временем поддержка <tt/a.out/ будет убрана из
|
||
ядра GENERIC, и постепенно убрана из системы совсем, как только отпадёт
|
||
нужда в запуске старых программ в формате <tt/a.out/.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему невозможно изменить права на символические ссылки?
|
||
</heading>
|
||
|
||
<p>Чтобы это работало, используйте опции ``<tt/-H/'' или ``<tt/-L/''
|
||
вместе с опцией ``<tt/-R/''. Обратитесь к страницам Справочника по
|
||
команде <htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod"
|
||
name="chmod"> и по <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?symlink" name="symlink">.
|
||
|
||
<p><bf/ПРЕДУПРЕЖДЕНИЕ/ опция ``<tt/-R/'' выполняет команду <tt/chmod/
|
||
<bf/РЕКУРСИВНО/. Будьте осторожны, задавая каталоги или символические
|
||
ссылки на каталоги в параметрах <tt/chmod/. Если вы хотите изменить
|
||
права на каталог, на который указывает символическая ссылка, используйте
|
||
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod">
|
||
без опций и следуйте символической ссылке с помощью лидирующего слэша
|
||
(``<tt>/</tt>''). Например, если ``<tt/foo/'' является символической
|
||
ссылкой на каталог ``<tt/bar/'', а вы хотите изменить права на
|
||
``<tt/foo/'' (на самом деле ``<tt/bar/''), вы должны выполнить команду
|
||
типа следующей:
|
||
|
||
<verb>
|
||
chmod 555 foo/
|
||
</verb>
|
||
|
||
<p>Если задан лидирующий слэш, <htmlurl
|
||
url="http://www.freebsd.org/cgi/man.cgi?chmod" name="chmod"> будет
|
||
следовать символической ссылке, ``<tt/foo/'', меняя права на каталог
|
||
``<tt/bar/''.
|
||
|
||
<sect1>
|
||
<heading>
|
||
Почему длина регистрационного имени <bf/всё ещё/ ограничена
|
||
8 символами?
|
||
</heading>
|
||
|
||
<p>Наверное, вы думаете, что достаточно будет изменить значение
|
||
константы <bf/UT_NAMESIZE/, перекомпилировать полностью систему
|
||
и всё будет работать. К несчастью, часть приложений и утилит (включая
|
||
системные) имеют жёстко заданные малые значения (не всегда "8" или
|
||
"9", но и такие странные, как "15" или "20") в структурах и буферах.
|
||
Это приведёт не только к порче файлов журналов (из-за записи полей
|
||
переменного размера там, где ожидается поле фиксированного размера), но
|
||
может повлиять на работу клиентов системы Sun NIS и может в принципе
|
||
вызвать другие проблемы при взаимодействии с другими системами UNIX.
|
||
|
||
<p>Во FreeBSD 3.0 и старше, максимальная длина имени была увеличена
|
||
до 16 символов и все утилиты с предопределённым размером имени были
|
||
найдены и исправлены. Так как это касается столь многих областей в
|
||
системе, то такие изменения не делались вплоть до 3.0. </p>
|
||
|
||
<p>Если вы абсолютно уверены, что сможете найти и исправить проблемы
|
||
такого рода самостоятельно, когда они возникнут, то можете увеличить
|
||
длину регистрационного имени в ранних релизах, отредактировав файл
|
||
/usr/include/utmp.h и изменив соответствующим образом константу
|
||
UT_NAMESIZE. Вы должны будете также изменить значение MAXLOGNAME в
|
||
файле /usr/include/sys/param.h, чтобы оно соответствовало UT_NAMESIZE.
|
||
И наконец, если вы компилируете из исходных текстов, не забудьте, что
|
||
/usr/include обновляется каждый раз! Делайте изменения в
|
||
соответствующих файлах каталога /usr/src/.. </p>
|
||
|
||
<sect1>
|
||
<heading>Можно ли запускать программы для DOS во FreeBSD?</heading>
|
||
|
||
<p>Да, начиная с версии 3.0, вы можете использовать эмулятор DOS
|
||
<tt/rundos/ от BSDI, который был интегрирован в систему и
|
||
усовершенствован. Пошлите письмо в <url
|
||
url="mailto:freebsd-emulation@freebsd.org" name="список рассылки">,
|
||
посвящённый эмуляции во FreeBSD, если вы заинтересованы в участии в
|
||
этом проекте.
|
||
|
||
<p>Для систем, предшествовавшим 3.0, в коллекции портов есть
|
||
замечательная утилита <htmlurl
|
||
url="http://www.freebsd.org/cgi/ports.cgi?^pcemu" name="pcemu">,
|
||
эмулирующая процессор 8088 и функции BIOS, чего достаточно для запуска
|
||
приложений DOS, работающих в текстовом режиме. Она требует X Window
|
||
System (которая поставляется как XFree86).
|
||
|
||
<sect1>
|
||
<heading>
|
||
Что такое ``<tt/sup/'' и как это можно использовать?
|
||
</heading>
|
||
|
||
<p>Сокращение <htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^sup"
|
||
name="SUP"> означает Software Update Protocol, который был разработан в
|
||
CMU для синхронизации исходных текстов. Мы используем его для
|
||
синхронизации исходных текстов на удалённых сайтах с основным сервером
|
||
разработчиков.
|
||
|
||
<p>Протокол SUP использует пропускную способность канала неэффективно,
|
||
и был отвергнут. В настоящее время рекомендуемым методом для
|
||
синхронизации исходных текстов является протокол <url
|
||
url="../../handbook/synching.html#CVSUP" name="CVSup">.
|
||
|
||
<sect1>
|
||
<heading>Насколько греется процессор при работе FreeBSD?</heading>
|
||
|
||
<p>В. Кто-нибудь делал замеры температуры при работе FreeBSD? Я
|
||
знаю, что Linux греется меньше, чем DOS, но никогда не видел упоминания
|
||
FreeBSD. Наверное, он сильно греется.
|
||
|
||
<p>О. Нет, но мы сделали различные вкусовые тесты у добровольцев с
|
||
завязанными глазами, которые до этого приняли по 250 микрограмм
|
||
LSD-25. 35% добровольцев заявило, что FreeBSD имеет вкус апельсина,
|
||
тогда как вкус Linux расценивался как фиолетовый туман. Насколько
|
||
я помню, ни одна из групп не отметила значительной разницы в
|
||
температуре. Вы хотели опубликовать полные результаты этого опроса,
|
||
когда обнаружиди, что слишком много добровольцев покинули помещение
|
||
во время тестов, что несколько смазало результаты. Я думаю, что
|
||
большинство из них работают сейчас в Apple над их новым GUI
|
||
``чеши и нюхай''. Это старый добрый бизнес!
|
||
|
||
<p>Серьёзно, и FreeBSD, и Linux используют инструкцию ``<tt/HLT/''
|
||
(halt), когда система простаивает, что уменьшает потребление энергии
|
||
и в свою очередь, выделение тепла. Вдобавок, если у вас настроен
|
||
APM (автоматическое управление энергопотреблением), то FreeBSD
|
||
может переводить процессор в режим пониженного энергопотребления.
|
||
|
||
<sect1>
|
||
<heading>Кто там скребётся в микросхемах памяти??</heading>
|
||
|
||
<p>В. Делает ли FreeBSD что-нибудь эдакое при компиляции ядра, что
|
||
вызывает поскрипывание микросхем памяти? При компиляции (и в короткий
|
||
промежуток времени после обнаружения дисковода при старте системы)
|
||
от микросхем памяти исходит странный царапающий звук.
|
||
|
||
<p>О. Да! Вы, наверное, видели частое упоминание ``даемонов'' в
|
||
документации по BSD, но не многие знают, что это настоящие нематериальные
|
||
существа, которые теперь завладели вашим компьютером. Царапающий звук,
|
||
издаваемый микросхемами памяти - это на самом деле высокочастотное
|
||
перешёптывание между даемонами, когда они решают, как лучше справиться
|
||
с различными задачами по администрированию системы.
|
||
|
||
<p>Если шум достиг ваших ушей. команда DOS ``<tt>fdisk /mbr</tt>''
|
||
их спугнёт, но не удивляйтесь, если они отреагируют соответствующим
|
||
образом и попытаются вас остановить. Фактически, если во время
|
||
выполнения этой команды вы услышите сатанинский голос Билла Гейтса из
|
||
встроенного динамика, бегите и даже не оглядывайтесь! Избавленные
|
||
от противостояния с даемонами BSD, близнецы-демоны DOS и Windows часто
|
||
могут захватить полный контроль не только над вашей машиной и
|
||
навлечь вечное проклятие на вашу душу. Если бы у меня был выбор, я
|
||
думаю, что предпочту царапающий звук.
|
||
|
||
<sect1>
|
||
<heading>Что такое 'MFC'?</heading>
|
||
|
||
<p>MFC это сокращение от 'Merged From -CURRENT.' Оно используется в
|
||
протоколах изменений CVS для отметки того, что изменение было
|
||
перенесено в ветвь STABLE из CURRENT.
|
||
|
||
<sect1>
|
||
<heading>Что означает сокращение 'BSD'?</heading>
|
||
|
||
<p>Это сокращение значит что-то на секретном языке, который могут знать
|
||
только посвящённые. Это нельзя перевести один к одному, однако
|
||
достаточно сказать, что перевод с BSD - это что-то между 'Команда
|
||
Formula-1", 'Пингвины - это вкусные плюшки' и 'Мы прикольнее, чем
|
||
Linux.' :-)
|
||
|
||
<p>Если серьёзно, то BSD является сокращением от 'Berkeley Software
|
||
Distribution', названия, которое было выбрано Berkeley CSRG (Computer
|
||
Systems Research Group) для их дистрибутива Unix.
|
||
|
||
</sect>
|
||
|