MFen: articles/cups/article.sgml 1.3 --> 1.5

articles/vm-design/article.sgml  1.15 -->  1.18

ru_RU.KOI8-R/articles/cups/article.sgml

@@ -3,7 +3,7 @@
 
      $FreeBSD$
 
-     Original revision: 1.3
+     Original revision: 1.5
 -->
 
 <!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@@ -108,7 +108,20 @@ Translation:	Taras Korenko,
     <programlisting>[system=10]
 add path 'unlpt*' mode 0660 group cups
 add path 'ulpt*' mode 0660 group cups
-add path 'lpt*' mode 0660 group cups</programlisting>
+add path 'lpt*' mode 0660 group cups
+add path 'usb/<replaceable>X</replaceable>.<replaceable>Y</replaceable>.<replaceable>Z</replaceable>' mode 0660 group cups</programlisting>
+
+    <note>
+      <para>Замените <replaceable>X</replaceable>,
+	<replaceable>Y</replaceable> и <replaceable>Z</replaceable> номерами
+	соответствующего принтеру целевого устройства USB, отображаемого
+	в каталоге <filename class="directory">/dev/usb</filename>.  Чтобы
+	найти требуемые значения, просмотрите вывод &man.dmesg.8; и найдите
+	связанное с вашим принтером имя специального устройства
+	<filename>ugen<replaceable>X</replaceable>.<replaceable>Y</replaceable></filename>,
+	последнее будет символической ссылкой на искомое устройство в каталоге
+	<filename class="directory">/dev/usb</filename>.</para>
+    </note>
 
     <para>úÁÔÅÍ, ÄÏÂÁ×ØÔÅ ÓÌÅÄÕÀÝÉÅ Ä×Å ÚÁÐÉÓÉ ×
       <filename>/etc/rc.conf</filename>:</para>

ru_RU.KOI8-R/articles/vm-design/article.sgml

@@ -4,7 +4,7 @@
      $FreeBSD$
      $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/vm-design/article.sgml,v 1.7 2005/06/11 13:41:40 gad Exp $
 
-     Original revision: 1.15
+     Original revision: 1.18
 -->
 
 <!DOCTYPE ARTICLE PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
@@ -14,7 +14,7 @@
 
 <article lang="ru">
   <articleinfo>
-    <title>Элементы архитектуры системы виртуальной памяти во FreeBSD</title>
+    <title>Элементы архитектуры системы виртуальной памяти во &os;</title>
 
     <authorgroup>
       <author>
@@ -45,7 +45,7 @@
     <abstract>
       <para>Название статьи говорит лишь о том, что я попытаюсь описать в целом
         VM-систему понятным языком.  Последний год я сосредоточил усилия в
-        работе над несколькими основными подсистемами ядра FreeBSD, среди
+        работе над несколькими основными подсистемами ядра &os;, среди
         которых подсистемы VM и подкачки были самыми интересными, а NFS
         оказалась <quote>необходимой рутиной</quote>.  Я переписал лишь малую
         часть кода.  Что касается VM, то я единственным большим обновлением,
@@ -64,7 +64,7 @@
       <para>Первоначально эта статья была опубликована в номере <ulink
         url="http://www.daemonnews.org/">DaemonNews</ulink> за январь 2000
         года.  Эта версия статьи может включать добавления, касающиеся
-        изменений в реализации VM во FreeBSD от Мэтта и других авторов.</para>
+        изменений в реализации VM во &os; от Мэтта и других авторов.</para>
     </legalnotice>
   </articleinfo>
 
@@ -82,7 +82,7 @@
       считают BSD <quote>старой</quote> операционной системой, те их нас, кто
       работает над ней, видят ее скорее системой со <quote>зрелым</quote> кодом
       с различными компонентами, которые были заменены, расширены или изменены
-      современным кодом.  Он развивается, и FreeBSD остается передовой
+      современным кодом.  Он развивается, и &os; остается передовой
       системой, вне зависимости от того, насколько старой может быть часть
       кода.  Это важное отличие, которое, к сожалению, не всеми понимается.
       Самой большой ошибкой, которую может допустить программист, является
@@ -101,37 +101,48 @@
       отсутствует</quote> и <quote>мы всегда правы, потому что так говорит наш
       отдел продаж</quote>. Я плохо переношу тех, кого не учит история.</para>
 
-    <para>Большинство очевидной сложности архитектуры FreeBSD, особенно в
+    <para>Большинство очевидной сложности архитектуры &os;, особенно в
       подсистеме VM/Swap, является прямым следствием того, что она решает
       серьезные проблемы с производительностью, которые проявляются при
       различных условиях.  Эти проблемы вызваны не плохой проработкой
       алгоритмов, а возникают из окружающих факторов.  В любом прямом сравнении
       между платформами эти проблемы проявляются, когда системные ресурсы
-      начинают истощаться.  Так как я описываю подсистему VM/Swap во FreeBSD,
+      начинают истощаться.  Так как я описываю подсистему VM/Swap во &os;,
-      то читатель должен всегда иметь в виду два обстоятельства.  Во-первых,
+      то читатель должен всегда иметь в виду два обстоятельства:</para>
-      самым важным аспектом при проектировании производительности является то,
+
-      что называется &ldquo;оптимизацией критического маршрута&rdquo;.  Часто
+    <orderedlist>
-      случается, что оптимизация производительности дает прирост объема кода
+      <listitem>
-      ради того, чтобы критический маршрут работал быстрее.  Во-вторых,
+	<para>Самым важным аспектом при проектировании производительности
-      четкость общей архитектуры оказывается лучше сильно оптимизированной
+	  является то, что называется &ldquo;оптимизацией критического
-      архитектуры с течением времени.  Когда как обобщенная архитектура
+	  маршрута&rdquo;.  Часто случается, что оптимизация производительности
-      может быть медленнее, чем оптимизированная архитектура, при первой
+	  дает прирост объема кода ради того, чтобы критический маршрут
-      реализации, при обобщенной архитектуре легче подстраиваться под
+	  работал быстрее.</para>
-      изменяющиеся условия и чрезмерно оптимизированная архитектура оказывается
+      </listitem>
-      непригодной.  Любой код, который должен выжить и поддаваться поддержке
+
+      <listitem>
+	<para>Четкость общей архитектуры оказывается лучше сильно
+	  оптимизированной архитектуры с течением времени.  Когда как
+	  обобщенная архитектура может быть медленнее, чем оптимизированная
+	  архитектура, при первой реализации, при обобщенной архитектуре легче
+	  подстраиваться под изменяющиеся условия и чрезмерно оптимизированная
+	  архитектура оказывается непригодной.</para>
+      </listitem>
+    </orderedlist>
+
+    <para>Любой код, который должен выжить и поддаваться поддержке
       годы, должен поэтому быть тщательно продуман с самого начала, даже если
       это стоит потери производительности.  Двадцать лет назад были те, кто
       отстаивал преимущество программирования на языке ассемблера перед
       программированием на языке высокого уровня, потому что первый генерировал
       в десять раз более быстрый код.  В наши дни ошибочность этого аргумента
-      очевидна&mdash;можно провести параллели с построением алгоритмов и
+      очевидна&nbsp;&mdash;&nbsp;можно провести параллели с построением
-      обобщением кода.</para>
+      алгоритмов и обобщением кода.</para>
   </sect1>
 
   <sect1 id="vm-objects">
     <title>Объекты VM</title>
 
-    <para>Лучше всего начать описание VM-системы FreeBSD с попытки взглянуть на
+    <para>Лучше всего начать описание VM-системы &os; с попытки взглянуть на
       нее с точки зрения пользовательского процесса.  Каждый пользовательский
       процесс имеет единое, принадлежащее только ему и неразрывное адресное
       пространство VM, содержащее несколько типов объектов памяти.  Эти объекты
@@ -177,7 +188,7 @@
       потомок) полагают, что их собственные изменения после разветвления будут
       принадлежать только им, и не затронут родственный процесс.</para>
 
-    <para>FreeBSD управляет всем этим при помощи многоуровневой модели
+    <para>&os; управляет всем этим при помощи многоуровневой модели
       VM-объектов.  Исходный файл с двоичной программой переносится на самый
       нижний уровень объектов VM.  Уровень страниц, копируемых при записи,
       находится выше него, и хранит те страницы, которые были скопированы из
@@ -261,7 +272,7 @@
       быть уничтожена, если она не представляет собой <quote>реального</quote>
       файла).
       Однако такую оптимизацию не так уж просто осуществить, потому что она
-      делается на уровне мелких единиц.  Во FreeBSD такая оптимизация не
+      делается на уровне мелких единиц.  Во &os; такая оптимизация не
       выполняется.  Теперь положим (а это часто случается), что порожденный
       процесс выполняет вызов <function>exec()</function>.  Его текущее
       адресное пространство обычно заменяется новым адресным пространством,
@@ -303,7 +314,7 @@
       копии страницы, а исходная страница в B становится никому не доступной.
       такая страница в B может быть высвобождена.</para>
 
-    <para>FreeBSD решает проблему с глубиной вложенности с помощью приема
+    <para>&os; решает проблему с глубиной вложенности с помощью приема
       оптимизации, который называется &ldquo;All Shadowed Case&rdquo;.  Этот
       случай возникает, если в C1 либо C2 возникает столько случаев копирования
       страниц при записи, что они полностью закрывают все страницы в B.
@@ -337,7 +348,7 @@
       то, что вы можете построить сравнительно сложную иерархию объектов VM,
       которая несколько замедляет обработку ситуаций отсутствия страниц памяти,
       и к тому же тратится память на управление структурами объектов VM.
-      Приемы оптимизации, применяемые во FreeBSD, позволяют снизить значимость
+      Приемы оптимизации, применяемые во &os;, позволяют снизить значимость
       этих проблем до степени, когда их можно без особых потерь
       игнорировать.</para>
   </sect1>
@@ -352,52 +363,94 @@
       когда VM-системе нужно использовать ее повторно для других целей.  В
       этот момент на помощь приходит область подкачки.  Область подкачки
       выделяется для организации хранилища памяти, которая иначе не может быть
-      доступна.  FreeBSD создает структуру управления подкачкой для объекта
+      доступна.  &os; создает структуру управления подкачкой для объекта
       VM, только когда это действительно нужно.  Однако структура управления
-      подкачкой исторически имела некоторые проблемы.</para>
+      подкачкой исторически имела некоторые проблемы:</para>
 
-    <para>Во FreeBSD 3.X в структуре управления областью подкачки
+    <itemizedlist>
-      предварительно выделяется массив, который представляет целый объект,
+      <listitem>
-      требующий хранения в области подкачки&mdash;даже если только несколько
+	<para>Во &os; 3.X в структуре управления областью подкачки
-      страниц этого объекта хранятся в области подкачки.  Это создает проблему
+	  предварительно выделяется массив, который представляет целый объект,
-      фрагментации памяти ядра в случае, когда в память отображаются большие
+	  требующий хранения в области подкачки&mdash;даже если только
-      объекты или когда ветвятся процессы, занимающие большой объем памяти при
+	  несколько страниц этого объекта хранятся в области подкачки.  Это
-      работе (RSS).  Также для отслеживания памяти подкачки в памяти ядра
+	  создает проблему фрагментации памяти ядра в случае, когда в память
-      поддерживается <quote>список дыр</quote>, и он также несколько
+	  отображаются большие объекты или когда ветвятся процессы, занимающие
-      фрагментирован.  Так как <quote>список дыр</quote> является
+	  большой объем памяти при работе (RSS).</para>
-      последовательным списком,
+      </listitem>
-      то производительность при распределении и высвобождении памяти в области
-      подкачки неоптимально и ее сложность зависит от количества страниц как
-      O(n).  Также в процессе высвобождения памяти в области подкачки требуется
-      выделение памяти в ядре, и это приводит к проблемам блокировки при
-      недостатке памяти.  Проблема еще более обостряется из-за дыр, создаваемых
-      по чередующемуся алгоритму.  Кроме того, список распределения блоков в
-      области подкачки легко оказывается фрагментированной, что приводит к
-      распределению непоследовательных областей.  Память ядра также должна
-      распределяться по ходу работы для дополнительных структур по управлению
-      областью подкачки при выгрузке страниц памяти в эту область.  Очевидно,
-      что мест для усовершенствований предостаточно.</para>
 
-    <para>Во FreeBSD 4.X подсистема управления областью подкачки была полностью
+      <listitem>
-      переписана мною.  При этом структуры управления областью подкачки
+	<para>Также для отслеживания памяти подкачки в памяти ядра
-      распределяются при помощи хэш-таблицы, а не через линейный массив, что
+	  поддерживается <quote>список дыр</quote>, и он также несколько
-      дает им фиксированный размер при распределении и работу с гораздо
+	  фрагментирован.  Так как <quote>список дыр</quote> является
-      меньшими структурами.  Вместо того, чтобы использовать однонаправленный
+	  последовательным списком, то производительность при распределении
-      связный список для отслеживания выделения пространства в области
+	  и высвобождении памяти в области подкачки неоптимально и ее
-      подкачки, теперь используется побитовая карта блоков области подкачки,
+	  сложность зависит от количества страниц как O(n).</para>
-      выполненная в основном в виде древовидной структуры с информацией о
+      </listitem>
-      свободном пространстве, находящейся в узлах структур.  Это приводит к
+
-      тому, что выделение и высвобождение памяти в области подкачки становится
+      <listitem>
-      операцией сложности O(1).  Все дерево также распределяется заранее для
+	<para>Также в процессе высвобождения памяти в области подкачки
-      того, чтобы избежать распределения памяти ядра во время операций с
+	  требуется выделение памяти в ядре, и это приводит к проблемам
-      областью подкачки при критически малом объеме свободной памяти.  В конце
+	  блокировки при недостатке памяти.</para>
-      концов, система обращается к области подкачки при нехватке памяти, так
+      </listitem>
-      что мы должны избежать распределения памяти ядра в такие моменты для
+
-      избежания потенциальных блокировок.  Наконец, для уменьшения фрагментации
+      <listitem>
-      дерево может распределять большой последовательный кусок за раз,
+	<para>Проблема еще более обостряется из-за дыр, создаваемых
-      пропуская меньшие фрагментированные области.  Я не сделал последний шаг
+	  по чередующемуся алгоритму.</para>
-      к заведению <quote>указателя на распределение</quote>, который будет
+      </listitem>
-      передвигаться
+
+      <listitem>
+	<para>Кроме того, список распределения блоков в
+	  области подкачки легко оказывается фрагментированным, что приводит
+	  к распределению непоследовательных областей.</para>
+      </listitem>
+
+      <listitem>
+	<para>Память ядра также должна распределяться по ходу работы
+	  для дополнительных структур по управлению областью подкачки при
+	  выгрузке страниц памяти в эту область.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Очевидно, что мест для усовершенствований предостаточно.
+      Во &os; 4.X подсистема управления областью подкачки была полностью
+      переписана мною:</para>
+
+    <itemizedlist>
+      <listitem>
+	<para>Структуры управления областью подкачки распределяются при помощи
+	  хэш-таблицы, а не через линейный массив, что дает им фиксированный
+	  размер при распределении и работу с гораздо меньшими
+	  структурами.</para>
+      </listitem>
+
+      <listitem>
+	<para>Вместо того, чтобы использовать однонаправленный
+	  связный список для отслеживания выделения пространства в области
+	  подкачки, теперь используется побитовая карта блоков области
+	  подкачки, выполненная в основном в виде древовидной структуры
+	  с информацией о свободном пространстве, находящейся в узлах структур.
+	  Это приводит к тому, что выделение и высвобождение памяти в области
+	  подкачки становится операцией сложности O(1).</para>
+      </listitem>
+
+      <listitem>
+	<para>Все дерево также распределяется заранее для
+	  того, чтобы избежать распределения памяти ядра во время операций с
+	  областью подкачки при критически малом объеме свободной памяти.
+	  В конце концов, система обращается к области подкачки при нехватке
+	  памяти, так что мы должны избежать распределения памяти ядра в такие
+	  моменты для избежания потенциальных блокировок.</para>
+      </listitem>
+
+      <listitem>
+	<para>Для уменьшения фрагментации дерево может распределять большой
+	  последовательный кусок за раз, пропуская меньшие фрагментированные
+	  области.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Я не сделал последний шаг к заведению <quote>указателя на
+	распределение</quote>, который будет передвигаться
       по участку области подкачки при выделении памяти для обеспечения в
       будущем распределения последовательных участков, или по крайней мере
       местоположения ссылки, но я убежден, что это может быть сделано.</para>
@@ -420,7 +473,7 @@
       будет стоить нам сотни тысяч тактов работы центрального процессора и
       заметное замедление работы затронутых процессов, так что мы должны
       смириться со значительными издержками для того, чтобы была заведомо
-      выбрана правильная страница.  Вот почему FreeBSD превосходит другие
+      выбрана правильная страница.  Вот почему &os; превосходит другие
       системы в производительности при нехватке ресурсов памяти.</para>
 
     <para>Алгоритм определения свободной страницы написан на основе истории
@@ -451,10 +504,10 @@
         она снова нужна процессу и подгружать ее с диска.</para>
     </sidebar>
 
-    <para>FreeBSD использует несколько очередей страниц для обновления выбора
+    <para>&os; использует несколько очередей страниц для обновления выбора
       страниц для повторного использования, а также для определения того, когда
       же грязные страницы должны быть сброшены в хранилище.  Так как таблицы
-      страниц во FreeBSD являются динамическими объектами, практически ничего
+      страниц во &os; являются динамическими объектами, практически ничего
       не стоит вырезать страницу из адресного пространства любого использующего
       ее процесса.  После того, как подходящая страница, на основе счетчика
       использования, выбрана, именно это и выполняется.  Система должна
@@ -473,7 +526,7 @@
       использовать в LRU-порядке (меньше всего используемый), когда системе
       потребуется выделение дополнительной памяти.</para>
 
-    <para>Стоит отметить, что во FreeBSD VM-система пытается разделить чистые и
+    <para>Стоит отметить, что во &os; VM-система пытается разделить чистые и
       грязные страницы во избежание срочной необходимости в ненужных сбросах
       грязных страниц (что отражается на пропускной способности ввода/вывода) и
       не перемещает беспричинно страницы между разными очередями, когда
@@ -483,9 +536,11 @@
       очереди кэша мало, а счетчик активной очереди большой.  При повышении
       нагрузки на VM-систему она прилагает большие усилия на поддержку
       различных очередей страниц в соотношениях, которые являются наиболее
-      эффективными.  Годами ходили современные легенды, что Linux выполняет
+      эффективными.</para>
-      работу по предотвращению выгрузки на диск лучше, чем FreeBSD, но это не
+
-      так.  На самом деле FreeBSD старается сбросить на диск неиспользуемые
+    <para>Годами ходили современные легенды, что Linux выполняет
+      работу по предотвращению выгрузки на диск лучше, чем &os;, но это не
+      так.  На самом деле &os; старается сбросить на диск неиспользуемые
       страницы для освобождения места под дисковый кэш, когда как Linux хранит
       неиспользуемые страницы в памяти и оставляет под кэш и страницы процессов
       меньше памяти.  Я не знаю, остается ли это правдой на сегодняшний
@@ -504,9 +559,9 @@
       снова.  Если бинарный файл программы отображен в память, но не отображен
       в таблицу страниц, то все страницы, к которым обращалась программа,
       окажутся недоступными при каждом запуске программы.  Это не так уж
-      необходимо, если эти страницы уже присутствуют в кэше VM, так что FreeBSD
+      необходимо, если эти страницы уже присутствуют в кэше VM, так что &os;
       будет пытаться восстанавливать таблицы страниц процесса из тех страниц,
-      что уже располагаются в VM-кэше.  Однако во FreeBSD пока не выполняется
+      что уже располагаются в VM-кэше.  Однако во &os; пока не выполняется
       предварительное копирование при записи определенных страниц при выполнении
       вызова exec.  Например, если вы запускаете программу &man.ls.1;
       одновременно с работающей <command>vmstat 1</command>, то заметите, что
@@ -537,7 +592,7 @@
     <title>Оптимизация таблицы страниц</title>
 
     <para>Оптимизация таблицы страниц составляет самую содержательную часть
-      архитектуры VM во FreeBSD и она проявляется при появлении нагрузки при
+      архитектуры VM во &os; и она проявляется при появлении нагрузки при
       значительном использовании <function>mmap()</function>.  Я думаю, что это
       на самом деле особенность работы большинства BSD-систем, хотя я не
       уверен, когда это проявилось впервые.  Есть два основных подхода к
@@ -546,26 +601,26 @@
       любой момент с малыми накладными расходами.  Второй подход состоит в том,
       что каждая активная таблица страниц в системе имеет управляющую структуру
       <literal>pv_entry</literal>, которая связана в структуру
-      <literal>vm_page</literal>.  FreeBSD может просто просматривать эти
+      <literal>vm_page</literal>.  &os; может просто просматривать эти
       отображения, которые существуют, когда как в Linux должны проверяться все
       таблицы страниц, которые <emphasis>могут</emphasis> содержать нужное
       отображение, что в некоторых ситуация дает увеличение сложности O(n^2).
-      Из-за того, что FreeBSD стремится выбрать наиболее подходящую к
+      Из-за того, что &os; стремится выбрать наиболее подходящую к
       повторному использованию или сбросу в область подкачки страницу, когда
       ощущается нехватка памяти, система дает лучшую производительность при
-      нагрузке.  Однако во FreeBSD требуется тонкая настройка ядра для
+      нагрузке.  Однако во &os; требуется тонкая настройка ядра для
       соответствия ситуациям с большим совместно используемым адресным
       пространством, которые могут случиться в системе, обслуживающей сервер
       телеконференций, потому что структуры <literal>pv_entry</literal> могут
       оказаться исчерпанными.</para>
 
-    <para>И в Linux, и во FreeBSD требуются доработки в этой области.  FreeBSD
+    <para>И в Linux, и во &os; требуются доработки в этой области.  &os;
       пытается максимизировать преимущества от потенциально редко применяемой
       модели активного отображения (к примеру, не всем процессам нужно
       отображать все страницы динамической библиотеки), когда как Linux
-      пытается упростить свои алгоритмы.  FreeBSD имеет здесь общее преимущество
+      пытается упростить свои алгоритмы.  &os; имеет здесь общее преимущество
       в производительности за счет использования дополнительной памяти, но
-      FreeBSD выглядит хуже в случае, когда большой файл совместно используется
+      &os; выглядит хуже в случае, когда большой файл совместно используется
       сотнями процессов.  Linux, с другой стороны, выглядит хуже в случае,
       когда много процессов частично используют одну и ту же динамическую
       библиотеку, а также работает неоптимально при попытке определить, может
@@ -592,7 +647,7 @@
       и снижению производительности CPU.  Это так даже с множественными
       ассоциативными кэшами (хотя здесь эффект несколько сглажен).</para>
 
-    <para>Код выделения памяти во FreeBSD выполняет оптимизацию с применением
+    <para>Код выделения памяти во &os; выполняет оптимизацию с применением
       подгонки страниц, означающую то, что код выделения памяти будет пытаться
       найти свободные страницы, которые являются последовательными с точки
       зрения кэша.  Например, если страница 16 физической памяти назначается
@@ -617,7 +672,7 @@
       и алгоритмический подход, которому исторически следует BSD, позволяет нам
       изучить и понять существующую реализацию, а также сравнительно легко
       изменить большие блоки кода.  За несколько последних лет в VM-системе
-      FreeBSD было сделано некоторое количество усовершенствований, и работа
+      &os; было сделано некоторое количество усовершенствований, и работа
       над ними продолжается.</para>
   </sect1>
 
@@ -630,12 +685,12 @@
 	<question>
 	  <para>Что это за &ldquo;алгоритм чередования&rdquo;, который вы
             упоминали в списке недостатков подсистемы управления разделом
-            подкачки во FreeBSD 3.X?</para>
+            подкачки во &os; 3.X?</para>
 	</question>
 
 	<answer>
-	  <para>FreeBSD использует в области подкачки механизм чередования,
+	  <para>&os; использует в области подкачки механизм чередования,
-            с индексом по умолчанию, равным четырем.  Это означает, что FreeBSD
+            с индексом по умолчанию, равным четырем.  Это означает, что &os;
             резервирует пространство для четырех областей подкачки, даже если
             у вас имеется всего лишь одна, две или три области.  Так как в
             области подкачки имеется чередование, то линейное адресное
@@ -643,12 +698,12 @@
             будет фрагментироваться, если у вас нет на самом деле четырех
             областей подкачки.  Например, если у вас две области A и B, то
             представление адресного пространства для этой области подкачки во
-            FreeBSD будет организовано с чередованием блоков из 16
+            &os; будет организовано с чередованием блоков из 16
             страниц:</para>
 
 	  <literallayout>A B C D A B C D A B C D A B C D</literallayout>
 
-	  <para>FreeBSD 3.X использует <quote>последовательный список свободных
+	  <para>&os; 3.X использует <quote>последовательный список свободных
             областей</quote> для управления свободными областями в разделе
             подкачки.  Идея состоит в том, что большие последовательные блоки
             свободного пространства могут быть представлены при помощи узла
@@ -693,10 +748,17 @@
 
       <qandaentry>
 	<question>
+	  <para>Как разделение чистых и грязных (неактивных) страниц связано с
+            ситуацией, когда вы видите маленький счетчик очереди кэша и
+            большой счетчик активной очереди в выдаче команды
+	    <command>systat -vm</command>?  Разве системная статистика не
+            считает активные и грязные страницы вместе за счетчик активной
+            очереди?</para>
+
 	  <para>Я не понял следующее:</para>
 
 	  <blockquote>
-            <para>Стоит отметить, что во FreeBSD VM-система пытается разделить
+            <para>Стоит отметить, что во &os; VM-система пытается разделить
               чистые и грязные страницы во избежание срочной необходимости в
               ненужных сбросах грязных страниц (что отражается на пропускной
               способности ввода/вывода) и не перемещает беспричинно страницы
@@ -706,13 +768,6 @@
               системах значение счетчика очереди кэша мало, а счетчик активной
               очереди большой.</para>
 	  </blockquote>
-	  
-	  <para>Как разделение чистых и грязных (неактивных) страниц связано с
-            ситуацией, когда вы видите маленький счетчик очереди кэша и
-            большой счетчик активной очереди в выдаче команды
-	    <command>systat -vm</command>?  Разве системная статистика не
-            считает активные и грязные страницы вместе за счетчик активной
-            очереди?</para>
 	</question>
 
 	<answer>
@@ -721,7 +776,7 @@
             реальность такова, что пока у нас нет проблем с памятью, нам это на
             самом деле не нужно.</para>
 
-	  <para>Это означает, что FreeBSD не будет очень сильно стараться над
+	  <para>Это означает, что &os; не будет очень сильно стараться над
             отделением грязных страниц (неактивная очередь) от чистых страниц
             (очередь кэша), когда система не находится под нагрузкой, и не
             будет деактивировать страницы (активная очередь -> неактивная
@@ -737,7 +792,7 @@
             (COW из выполнимого файла в приватные страницы)?  То есть я
             полагаю, что ошибки доступа к страницам являются частично ошибками
             при заполнении нулями, а частично данных программы.  Или вы
-            гарантируете, что FreeBSD выполняет предварительно COW для данных
+            гарантируете, что &os; выполняет предварительно COW для данных
             программы?</para>
 	</question>
 
@@ -745,7 +800,7 @@
 	  <para>Ошибка COW может быть ошибкой при заполнении нулями или данных
             программы.  Механизм в любом случае один и тот же, потому что
             хранилище данных программы уже в кэше.  Я на самом деле не рад
-            ни тому, ни другому.  FreeBSD не выполняет предварительное COW
+            ни тому, ни другому.  &os; не выполняет предварительное COW
             данных программы и заполнение нулями, но она
             <emphasis>выполняет</emphasis> предварительно отображение страниц,
             которые имеются в ее кэше.</para>
@@ -762,7 +817,7 @@
             действие/реакцию должно потребоваться для сканирования
             отображений?</para>
 
-	  <para>Что делает Linux в тех случаях, когда FreeBSD работает плохо
+	  <para>Что делает Linux в тех случаях, когда &os; работает плохо
 	    (совместное использование отображения файла между многими
             процессами)?</para>
 	</question>
@@ -798,7 +853,7 @@
             страниц для каждого из этих 50 процессов, даже если только 10 из
             них на самом деле отображают страницу.  Так что Linux использует
             простоту подхода за счет производительности.  Многие алгоритмы VM,
-            которые имеют сложность O(1) или (N малое) во FreeBSD, в Linux
+            которые имеют сложность O(1) или (N малое) во &os;, в Linux
             приобретают сложность O(N), O(N^2) или хуже.  Так как pte,
             представляющий конкретную страницу в объекте, скорее всего, будет
             с тем же смещением во всех таблицах страниц, в которых они
@@ -807,12 +862,12 @@
             кэша L1 для этого смещения, что приводит к улучшению
             производительности.</para>
 
-	  <para>Во FreeBSD введены дополнительные сложности (схема с
+	  <para>Во &os; введены дополнительные сложности (схема с
             <literal>pv_entry</literal>) для увеличения производительности
             (уменьшая количество обращений <emphasis>только</emphasis> к тем
             pte, которые нужно модифицировать).</para>
 
-	  <para>Но во FreeBSD имеется проблема масштабирования, которой нет в
+	  <para>Но во &os; имеется проблема масштабирования, которой нет в
             Linux, потому что имеется ограниченное число структур
             <literal>pv_entry</literal>, и это приводит к возникновению проблем
             при большом объеме совместно используемых данных.  В этом случае
@@ -826,11 +881,11 @@
             схемы с <literal>pv_entry</literal>: Linux использует
 	    <quote>постоянные</quote> таблицы страниц, которые не сбрасываются,
             но ему не нужны <literal>pv_entry</literal> для каждого
-            потенциально отображаемого pte.  FreeBSD использует
+            потенциально отображаемого pte.  &os; использует
             <quote>сбрасываемые</quote> таблицы страниц, но для каждого
             реально отображаемого pte добавляется структура
             <literal>pv_entry</literal>.  Я думаю, что использование памяти
-            будет примерно одинакова, тем более что у FreeBSD есть
+            будет примерно одинакова, тем более что у &os; есть
             алгоритмическое преимущество, заключающееся в способности
             сбрасывать таблицы страниц с очень малыми накладными
             расходами.</para>