1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
|
<!-- $Id: misc.sgml,v 1.1 1998-12-28 19:20:04 ache Exp $ -->
<!-- The FreeBSD Russian Documentation Project -->
<sect>
<heading>Разное<label id="misc"></heading>
<sect1>
<heading>
FreeBSD использует гораздо больше места в свопе, чем Linux. Почему?
</heading>
<p>Это не так. Наверное, вас интересует, ``почему своп выглядит
переполненным?''. Если вы подразумевали именно это, то это объясняется
тем, что помещение страницы памяти в своп с последующим восстановлением
оттуда выполняется быстрее, чем её сброс с последующим взятием снова из
(неизменяемых) блоков выполнимого файла из файловой системы.
<p>Реальное количество ``грязных'' страниц памяти, которое вы можете
иметь в системе одновременно, не уменьшается; просто по необходимости
происходит сброс ``чистых'' страниц.
<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/cvsup.html" 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.
</sect>
|
