A: Это только кажется, что для FreeBSD требуется больше места на разделе подкачки, чем для Linux. На самом деле это не так. Главное отличие FreeBSD от Linux в этом плане заключается в том, что FreeBSD активно перемещает неиспользуемые страницы памяти, к которым не было обращений, в раздел подкачки, чтобы увеличить объём доступной физической памяти для активного использования. Linux же перемещает страницы памяти в раздел подкачки только в крайнем случае. Получаемое во FreeBSD увеличение нагрузки на раздел подкачки компенсируется более эффективным использованием оперативной памяти.
Заметьте, что, хотя FreeBSD предпочитает использовать раздел подкачки, она не может сбросить все неактивные страницы в своп при полностью неактивной системе. Так что вряд ли может возникнуть ситуация, когда, проснувшись рано утром, вы обнаружите, что вся ваша система находится в разделе подкачки, хотя она простаивала всю ночь.
A: Для понимания того, почему FreeBSD использует формат a.out, вы должны сначала получить представление о трёх "основных" форматах выполнимых файлов для UNIX:
Это самый старый, `классический' формат объектных файлов для 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 за подробной информацией.
FreeBSD выросла на "классических" традициях и традиционно использовала формат a.out, технологию, опробованную и проверенную во многих вариациях 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: Если вернуться в далёкое тёмное прошлое, то тогда компьютеры были очень просто устроены. На них могла работать простая, маленькая система. Формат 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.
A: Чтобы это работало, используйте опции ``-H'' или ``-L'' вместе с опцией ``-R''. Обратитесь к страницам Справочника по команде chmod и по symlink.
ПРЕДУПРЕЖДЕНИЕ опция ``-R'' выполняет команду chmod РЕКУРСИВНО. Будьте осторожны, задавая каталоги или символические ссылки на каталоги в параметрах chmod. Если вы хотите изменить права на каталог, на который указывает символическая ссылка, используйте chmod без опций и следуйте символической ссылке с помощью лидирующего слэша (``/''). Например, если ``foo'' является символической ссылкой на каталог ``bar'', а вы хотите изменить права на ``foo'' (на самом деле ``bar''), вы должны выполнить команду типа следующей:
════════chmod═555═foo/
══════
Если задан лидирующий слэш, chmod будет следовать символической ссылке, ``foo'', меняя права на каталог ``bar''.
A: Наверное, вы думаете, что достаточно будет изменить значение константы 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/..
A: Да, начиная с версии 3.0, вы можете использовать эмулятор DOS doscmd от BSDI, который был интегрирован в систему и усовершенствован. Пошлите письмо в список рассылки, посвящённый эмуляции во FreeBSD, если вы заинтересованы в участии в этом проекте.
Для систем, предшествующих 3.0, в коллекции портов есть замечательная утилита pcemu, эмулирующая процессор 8088 и функции BIOS, чего достаточно для запуска приложений DOS, работающих в текстовом режиме. Она требует X Window System (которая поставляется как XFree86).
A: Сокращение SUP означает Software Update Protocol, который был разработан в CMU для синхронизации исходных текстов. Мы используем его для синхронизации исходных текстов на удалённых сайтах с основным сервером разработчиков.
Протокол SUP использует пропускную способность канала неэффективно, и был отвергнут. В настоящее время рекомендуемым методом для синхронизации исходных текстов является протокол CVSup.
A: В. Кто-нибудь делал замеры температуры при работе FreeBSD? Я знаю, что Linux греется меньше, чем DOS, но никогда не видел упоминания FreeBSD. Наверное, он сильно греется.
О. Нет, но мы сделали различные вкусовые тесты у добровольцев с завязанными глазами, которые до этого приняли по 250 микрограмм LSD-25. 35% добровольцев заявило, что FreeBSD имеет вкус апельсина, тогда как вкус Linux расценивался как фиолетовый туман. Насколько я помню, ни одна из групп не отметила значительной разницы в температуре. Вы хотели опубликовать полные результаты этого опроса, когда обнаружиди, что слишком много добровольцев покинули помещение во время тестов, что несколько смазало результаты. Я думаю, что большинство из них работают сейчас в Apple над их новым GUI ``чеши и нюхай''. Это старый добрый бизнес!
Серьёзно, и FreeBSD, и Linux используют инструкцию ``HLT'' (halt), когда система простаивает, что уменьшает потребление энергии и в свою очередь, выделение тепла. Вдобавок, если у вас настроен APM (автоматическое управление энергопотреблением), то FreeBSD может переводить процессор в режим пониженного энергопотребления.
A: В. Делает ли FreeBSD что-нибудь эдакое при компиляции ядра, что вызывает поскрипывание микросхем памяти? При компиляции (и в короткий промежуток времени после обнаружения дисковода при старте системы) от микросхем памяти исходит странный царапающий звук.
О. Да! Вы, наверное, видели частое упоминание ``даемонов'' в документации по BSD, но не многие знают, что это настоящие нематериальные существа, которые теперь завладели вашим компьютером. Царапающий звук, издаваемый микросхемами памяти - это на самом деле высокочастотное перешёптывание между даемонами, когда они решают, как лучше справиться с различными задачами по администрированию системы.
Если шум достиг ваших ушей. команда DOS ``fdisk /mbr'' их спугнёт, но не удивляйтесь, если они отреагируют соответствующим образом и попытаются вас остановить. Фактически, если во время выполнения этой команды вы услышите сатанинский голос Билла Гейтса из встроенного динамика, бегите и даже не оглядывайтесь! Избавленные от противостояния с даемонами BSD, близнецы-демоны DOS и Windows часто могут захватить полный контроль не только над вашей машиной и навлечь вечное проклятие на вашу душу. Если бы у меня был выбор, я думаю, что предпочту царапающий звук.
A: MFC это сокращение от 'Merged From -CURRENT.' Оно используется в протоколах изменений CVS для отметки того, что изменение было перенесено в ветвь STABLE из CURRENT.
A: Это сокращение значит что-то на секретном языке, который могут знать только посвящённые. Это нельзя перевести один к одному, однако достаточно сказать, что перевод с BSD - это что-то между 'Команда Formula-1", 'Пингвины - это вкусные плюшки' и 'Мы прикольнее, чем Linux.' :-)
Если серьёзно, то BSD является сокращением от 'Berkeley Software Distribution', названия, которое было выбрано Berkeley CSRG (Computer Systems Research Group) для их дистрибутива Unix.
A: Необходимо иметь ровно одну тысячу сто семьдесят два разработчика:
Двадцать три сообщат в -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) добавил:
Я сильно смеялся над всем этим.
И тогда я подумал, "Постойте-ка, найдётся ли кто-нибудь, чтобы задокументировать это где-нибудь?"
И на меня снизошло озарение :-)
Авторские права на этот параграф: Copyright (c) 1999 Dag-Erling CoОdan SmЬrgrav. Пожалуйста, не воспроизводите этот материал без указания авторских прав.