-Одним из наиболее важных требований является дисковое пространство. В зависимости от набора релизов, архитектур и степени полноты зеркала вам может потребоваться огромный объем диска. Не лишним будет помнить, что _официальное_ зеркало, скорее всего, должно быть полным. Веб-страницы всегда должны зеркалироваться полностью. Кроме того, учтите, что приводимые оценки объема относятся к состоянию на момент последнего редактирования данной статьи ({rel120-current}-RELEASE/{rel113-current}-RELEASE). Дальнейший процесс разработки и последующие релизы только увеличат требуемый объем. Кроме того, разумно будет зарезервировать некоторое (10-20%) дополнительное пространство спокойствия ради. Вот некоторые оценки объема:
+Одним из наиболее важных требований является дисковое пространство. В зависимости от набора релизов, архитектур и степени полноты зеркала вам может потребоваться огромный объём диска. Не лишним будет помнить, что _официальное_ зеркало, скорее всего, должно быть полным. Веб-страницы всегда должны зеркалироваться полностью. Кроме того, учтите, что приводимые оценки объёма относятся к состоянию на момент последнего редактирования данной статьи ({rel120-current}-RELEASE/{rel113-current}-RELEASE). Дальнейший процесс разработки и последующие релизы только увеличат требуемый объём. Кроме того, разумно будет зарезервировать некоторое (10-20%) дополнительное пространство спокойствия ради. Вот некоторые оценки объёма:
* Полное зеркало FTP: 1.4 TB
* Комплект изменений CTM: 10 GB
@@ -85,7 +85,7 @@
[[mirror-bandwidth]]
=== Требования к сетевой связности и пропускной способности
-Разумеется, у вас должно быть подключение к интернет. Требуемая пропускная способность ваших каналов зависит от предполагаемого профиля использования вашего зеркала. Если вы собираетесь копировать некоторые части FreeBSD для локального использования на вашей машине или в интранете, требования могут быть много мягче, чем для публичного зеркала. Для официального зеркала необходимая пропускная способность увеличивается еще больше. Мы можем дать лишь очень грубые оценки:
+Разумеется, у вас должно быть подключение к интернет. Требуемая пропускная способность ваших каналов зависит от предполагаемого профиля использования вашего зеркала. Если вы собираетесь копировать некоторые части FreeBSD для локального использования на вашей машине или в интранете, требования могут быть много мягче, чем для публичного зеркала. Для официального зеркала необходимая пропускная способность увеличивается ещё больше. Мы можем дать лишь очень грубые оценки:
* Зеркало для локального доступа: фактически минимум не определен, но канал шириной менее 2 Mbps может сделать процесс обновления мучительно медленным.
* Неофициальное публичное зеркало: 34 Mbps выглядит неплохо для начала.
@@ -110,7 +110,7 @@
[[mirror-serv-ftp]]
==== FTP (требуется для FTP зеркала)
-Это один из наиболее базовых сервисов; его предоставление требуется для каждого зеркала, распространяющего файлы FreeBSD по FTP. Доступ по FTP должен быть анонимным, и не должны применяться какие-либо ограничения по соотношению объема передано/принято (что вообще является, на наш взгляд, странным подходом). Закачка (upload) файлов на сервер не требуется (и _должна_ быть запрещена в разделе FreeBSD). Кроме того, архив файлов FreeBSD должен быть доступен с путем [.filename]#/pub/FreeBSD#.
+Это один из наиболее базовых сервисов; его предоставление требуется для каждого зеркала, распространяющего файлы FreeBSD по FTP. Доступ по FTP должен быть анонимным, и не должны применяться какие-либо ограничения по соотношению объёма передано/принято (что вообще является, на наш взгляд, странным подходом). Закачка (upload) файлов на сервер не требуется (и _должна_ быть запрещена в разделе FreeBSD). Кроме того, архив файлов FreeBSD должен быть доступен с путем [.filename]#/pub/FreeBSD#.
Для предоставления анонимного FTP доступа может быть использован целый ряд программ (перечислены в алфавитном порядке).
@@ -127,7 +127,7 @@
[[mirror-serv-rsync]]
==== Rsync (необязательный сервис для FTP зеркала)
-rsync часто используется для предоставления доступа к FTP-области FreeBSD, чтобы другие зеркала могли синхронизироваться по вашему. Протокол rsync во многом отличается от FTP, в частности, он гораздо гуманнее с точки зрения пропускной способности каналов, поскольку не требует передачи измененного файла целиком (передаются лишь различия). Взамен rsync требует значительных объемов памяти. Размер каждого процесса зависит от размера синхронизируемого модуля (в основном от количества каталогов и файлов). rsync может использовать в качестве транспортного протокола `rsh` или `ssh` (по умолчанию); также, может использоваться внутренний протокол rsync (этот метод предпочтителен для публичных rsync-серверов). Поддерживается авторизация клиентов и различные ограничения. Для протокола rsync существует единственный пакет:
+rsync часто используется для предоставления доступа к FTP-области FreeBSD, чтобы другие зеркала могли синхронизироваться по вашему. Протокол rsync во многом отличается от FTP, в частности, он гораздо гуманнее с точки зрения пропускной способности каналов, поскольку не требует передачи измененного файла целиком (передаются лишь различия). Взамен rsync требует значительных объёмов памяти. Размер каждого процесса зависит от размера синхронизируемого модуля (в основном от количества каталогов и файлов). rsync может использовать в качестве транспортного протокола `rsh` или `ssh` (по умолчанию); также, может использоваться внутренний протокол rsync (этот метод предпочтителен для публичных rsync-серверов). Поддерживается авторизация клиентов и различные ограничения. Для протокола rsync существует единственный пакет:
* package:net/rsync[]
@@ -240,7 +240,7 @@
[[mirror-where]]
== С какого сервера синхронизироваться
-Это важный вопрос, так что мы попытаемся пояснить, откуда берутся ответы. Для начала повторим еще несколько раз: _никогда не синхронизируйтесь с ftp.FreeBSD.org_.
+Это важный вопрос, так что мы попытаемся пояснить, откуда берутся ответы. Для начала повторим ещё несколько раз: _никогда не синхронизируйтесь с ftp.FreeBSD.org_.
[[mirror-where-organization]]
=== Организация системы зеркал
@@ -274,7 +274,7 @@
[[mirror-where-master]]
==== Мне нужен доступ к основным сайтам!
-При наличии достаточных причин вы можете получить доступ к одному из основных сайтов. Доступ к ним ограничен; существуют специальные правила их использования. Наличие у вас статуса _официального_ зеркала, безусловно, является хорошим подспорьем. В противном случае убедитесь, что ваша страна действительно нуждается еще в одном зеркале. Если их уже три или более, сначала свяжитесь с администратором соответствующей зоны DNS (mailto:hostmaster@CC.FreeBSD.org[hostmaster@CC.FreeBSD.org]) или напишите в {freebsd-hubs}.
+При наличии достаточных причин вы можете получить доступ к одному из основных сайтов. Доступ к ним ограничен; существуют специальные правила их использования. Наличие у вас статуса _официального_ зеркала, безусловно, является хорошим подспорьем. В противном случае убедитесь, что ваша страна действительно нуждается ещё в одном зеркале. Если их уже три или более, сначала свяжитесь с администратором соответствующей зоны DNS (mailto:hostmaster@CC.FreeBSD.org[hostmaster@CC.FreeBSD.org]) или напишите в {freebsd-hubs}.
Тот, кто помог вам стать _официальным_ зеркалом, должен был помочь вам получить доступ к соответствующему вышестоящему хосту — либо к одному из основных сайтов, либо к подходящему сайту уровня Tier-1. Если этого не произошло, вы можете отправить письмо по адресу mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org], чтобы запросить помощь в этом вопросе.
-Чтобы добавить их в вашу базу данных, вы можете использовать `slapadd` или `ldapadd` для файла, содержащего эти записи. Альтернативно, вы можете использовать package:sysutils/ldapvi[].
+Чтобы добавить их в вашу базу данных, вы можете использовать `slapadd` или `ldapadd` для файла, содержащего эти записи. Или вы можете использовать package:sysutils/ldapvi[].
Утилита `ldapsearch` на клиентской машине теперь должна возвращать эти записи. Если это так, ваша база данных правильно настроена для использования в качестве сервера аутентификации LDAP.
@@ -341,7 +341,7 @@
Строгое место, где эта строка появляется в файле, и какие опции указаны в четвертом столбце, определяют точное поведение механизма аутентификации; см. man:pam[d]
-С такой конфигурацией вы сможете аутентифицировать пользователя в LDAP-каталоге. PAM выполнит привязку с вашими учетными данными, и в случае успеха сообщит SSH разрешить доступ.
+С такой конфигурацией вы сможете аутентифицировать пользователя в LDAP-каталоге. PAM выполнит привязку с вашими учётными данными, и в случае успеха сообщит SSH разрешить доступ.
Однако разрешать _каждому_ пользователю в каталоге доступ к _каждой_ клиентской машине — не лучшая идея. При текущей конфигурации пользователю для входа на машину достаточно наличия записи в LDAP. К счастью, есть несколько способов ограничить доступ пользователей.
@@ -576,11 +576,11 @@
Это предотвратит возможность пользователей маскироваться под других пользователей.
[[secure-root]]
-=== Определение учетной записи `root`
+=== Определение учётной записи `root`
-Часто учетная запись `root` или администратора для службы LDAP будет определена в файле конфигурации. Например, OpenLDAP поддерживает это, и это работает, но может привести к проблемам, если файл [.filename]#slapd.conf# будет скомпрометирован. Возможно, лучше использовать это только для первоначальной настройки доступа к LDAP, а затем определить учетную запись `root` там.
+Часто учётная запись `root` или администратора для службы LDAP будет определена в файле конфигурации. Например, OpenLDAP поддерживает это, и это работает, но может привести к проблемам, если файл [.filename]#slapd.conf# будет скомпрометирован. Возможно, лучше использовать это только для первоначальной настройки доступа к LDAP, а затем определить учётную запись `root` там.
-Еще лучше определить учетные записи с ограниченными правами и полностью исключить учетную запись `root`. Например, пользователи, которые могут добавлять или удалять учетные записи, добавляются в одну группу, но сами не могут изменять состав этой группы. Такая политика безопасности поможет снизить последствия утечки пароля.
+Еще лучше определить учётные записи с ограниченными правами и полностью исключить учётную запись `root`. Например, пользователи, которые могут добавлять или удалять учётные записи, добавляются в одну группу, но сами не могут изменять состав этой группы. Такая политика безопасности поможет снизить последствия утечки пароля.
-* Импорт нового программного обеспечения, лицензированного под любыми лицензиями, кроме лицензии BSD и подобных лицензий BSD (как определено ниже), требует предварительного одобрения от FreeBSD Core Team. Запросы на импорт должны включать:
+* Импорт нового программного обеспечения, лицензированного под любыми лицензиями, кроме лицензии BSD и подобных лицензий BSD (как определено ниже), требует предварительного одобрения от Основной команды FreeBSD. Запросы на импорт должны включать:
** Список новых возможностей или исправлений ошибок, которые содержит новая версия или патчи, вместе с доказательствами того, что эти возможности нужны нашим пользователям. Идеальными формами доказательств являются PR (запросы на включение изменений) или ссылки на обсуждения в почтовых рассылках.
-** Этот процесс должен использоваться для всех импортов программного обеспечения, а не только для тех, которые требуют проверки Core Team. Сам факт существования новой версии не является оправданием для импорта программного обеспечения в исходные коды или порты.
+** Этот процесс должен использоваться для всех импортов программного обеспечения, а не только для тех, которые требуют проверки Основной команды (Core Team). Сам факт существования новой версии не является оправданием для импорта программного обеспечения в исходные коды или порты.
** Список ветвей FreeBSD, которые могут быть затронуты. Расширение области применения требует нового запроса и одобрения от основной команды FreeBSD.
* Лицензия Apache 2.0 допустима для использования в некоторых случаях. Основная команда должна одобрить импорт новых компонентов, лицензированных по лицензии Apache, или изменение лицензии существующих компонентов на лицензию Apache.
@@ -187,7 +187,7 @@
=== Только уведомление об авторских правах и выражение SPDX-License-Identifier.
-Некоторые файлы в дереве содержат отдельные лицензии. Эти файлы содержат только уведомление об авторских правах и выражение SPDX-License-Identifier, но не содержат явной лицензии. См. crossref:license-guide[expressions, Выражения SPDX-License-Identifier] для интерпретации выражения. Примечание: выражения, разрешенные для отдельных лицензий проектом, являются подмножеством выражений, используемых в информационных целях или определенных стандартом.
+Некоторые файлы в дереве содержат отдельные лицензии. Эти файлы содержат только уведомление об авторских правах и выражение SPDX-License-Identifier, но не содержат явной лицензии. См. crossref:license-guide[expressions, Выражения SPDX-License-Identifier] для интерпретации выражения. Примечание: выражения, разрешенные для отдельных лицензий проектом, являются подмножеством выражений, используемых в информационных целях или определённых стандартом.
Лицензия для файлов, содержащих только SPDX-License-Identifier, должна толковаться как
Общий API UNIX(R) определяет системный вызов как способ передачи команд из пользовательского процесса ядру. Наиболее распространённая реализация использует либо прерывание, либо специализированную инструкцию (например, инструкции `SYSENTER`/`SYSCALL` для ia32). Системные вызовы определяются по номеру. Например, в FreeBSD системный вызов номер 85 — это man:swapon[2], а номер 132 — man:mkfifo[2]. Некоторые системные вызовы требуют параметров, которые передаются из пользовательского пространства в пространство ядра различными способами (зависит от реализации). Системные вызовы являются синхронными.
-Еще один возможный способ взаимодействия — использование _прерывания_. Прерывания происходят асинхронно после возникновения определенного события (деление на ноль, ошибка страницы и т.д.). Прерывание может быть прозрачным для процесса (ошибка страницы) или привести к реакции, например, отправке _сигнала_ (деление на ноль).
+Еще один возможный способ взаимодействия — использование _прерывания_. Прерывания происходят асинхронно после возникновения определённого события (деление на ноль, ошибка страницы и т.д.). Прерывание может быть прозрачным для процесса (ошибка страницы) или привести к реакции, например, отправке _сигнала_ (деление на ноль).
[[proc-proc-comm]]
==== Обмен данными между процессами
@@ -93,7 +93,7 @@
[[thread-mgmt]]
==== Управление потоками
-Традиционный UNIX(R) не определяет никакого API или реализации для потоков, в то время как POSIX(R) определяет свой API для потоков, но реализация остается неопределенной. Традиционно существовало два способа реализации потоков: обработка их как отдельных процессов (потоки 1:1) или обертывание всей группы потоков в один процесс с управлением потоками в пользовательском пространстве (потоки 1:N). Сравнение основных особенностей каждого подхода:
+Традиционный UNIX(R) не определяет никакого API или реализации для потоков, в то время как POSIX(R) определяет свой API для потоков, но реализация остается неопределённой. Традиционно существовало два способа реализации потоков: обработка их как отдельных процессов (потоки 1:1) или обёртывание всей группы потоков в один процесс с управлением потоками в пользовательском пространстве (потоки 1:N). Сравнение основных особенностей каждого подхода:
Потоки 1:1
@@ -312,7 +312,7 @@
[[freebsd-atomic-op]]
===== Атомарные операции и барьеры памяти
-Атомарные операции реализуются через набор функций, выполняющих простые арифметические действия над операндами в памяти атомарным образом по отношению к внешним событиям (прерываниям, вытеснению и т. д.). Атомарные операции могут гарантировать атомарность только для небольших типов данных (порядка величины типа `.long` в архитектуре C), поэтому их следует редко использовать напрямую в конечном коде, разве что для очень простых операций (например, установки флага в битовой карте). На самом деле довольно просто и часто можно допустить семантическую ошибку, полагаясь только на атомарные операции (обычно называемые lock-less). Ядро FreeBSD предоставляет способ выполнения атомарных операций в сочетании с барьерами памяти. Барьеры памяти гарантируют, что атомарная операция произойдет в определенном порядке относительно других обращений к памяти. Например, если нам нужно, чтобы атомарная операция выполнилась только после завершения всех ожидающих операций записи (с точки зрения переупорядочивания буферов инструкций), нам необходимо явно использовать барьер памяти вместе с этой атомарной операцией. Таким образом, легко понять, почему барьеры памяти играют ключевую роль в построении высокоуровневых блокировок (таких как refcounts, мьютексы и т. д.). Для подробного объяснения атомарных операций обратитесь к man:atomic[9]. Однако важно отметить, что атомарные операции (и барьеры памяти тоже) в идеале должны использоваться только для построения фронтенд-блокировок (например, мьютексов).
+Атомарные операции реализуются через набор функций, выполняющих простые арифметические действия над операндами в памяти атомарным образом по отношению к внешним событиям (прерываниям, вытеснению и т. д.). Атомарные операции могут гарантировать атомарность только для небольших типов данных (порядка величины типа `.long` в архитектуре C), поэтому их следует редко использовать напрямую в конечном коде, разве что для очень простых операций (например, установки флага в битовой карте). На самом деле довольно просто и часто можно допустить семантическую ошибку, полагаясь только на атомарные операции (обычно называемые lock-less). Ядро FreeBSD предоставляет способ выполнения атомарных операций в сочетании с барьерами памяти. Барьеры памяти гарантируют, что атомарная операция произойдет в определённом порядке относительно других обращений к памяти. Например, если нам нужно, чтобы атомарная операция выполнилась только после завершения всех ожидающих операций записи (с точки зрения переупорядочивания буферов инструкций), нам необходимо явно использовать барьер памяти вместе с этой атомарной операцией. Таким образом, легко понять, почему барьеры памяти играют ключевую роль в построении высокоуровневых блокировок (таких как refcounts, мьютексы и т. д.). Для подробного объяснения атомарных операций обратитесь к man:atomic[9]. Однако важно отметить, что атомарные операции (и барьеры памяти тоже) в идеале должны использоваться только для построения фронтенд-блокировок (например, мьютексов).
[[freebsd-refcounts]]
===== Счетчики ссылок (refcount)
@@ -383,7 +383,7 @@
[[freebsd-schedpin]]
===== sched_pin/sched_unpin
-Еще один способ работы с вытеснением — это интерфейс `sched_pin()`. Если участок кода заключен между функциями `sched_pin()` и `sched_unpin()`, гарантируется, что соответствующий поток, даже если он может быть вытеснен, всегда будет выполняться на том же CPU. Закрепление очень эффективно в частном случае, когда нам необходимо обращаться к данным, привязанным к определенным CPU, и мы предполагаем, что другие потоки не изменят эти данные. Последнее условие делает критическую секцию избыточно строгим условием для нашего кода.
+Еще один способ работы с вытеснением — это интерфейс `sched_pin()`. Если участок кода заключен между функциями `sched_pin()` и `sched_unpin()`, гарантируется, что соответствующий поток, даже если он может быть вытеснен, всегда будет выполняться на том же CPU. Закрепление очень эффективно в частном случае, когда нам необходимо обращаться к данным, привязанным к определённым CPU, и мы предполагаем, что другие потоки не изменят эти данные. Последнее условие делает критическую секцию избыточно строгим условием для нашего кода.
[[freebsd-schedbind]]
===== sched_bind/sched_unbind
@@ -606,7 +606,7 @@
Поток в NPTL — это обычный процесс, у которого TGID не равен PID и есть групповой лидер, отличный от него самого (и, конечно, общая виртуальная память и т.д.). Все остальное происходит так же, как и с обычным процессом. Нет разделения общего состояния на внешнюю структуру, как в FreeBSD. Это создает некоторое дублирование информации и возможную несогласованность данных. Ядро Linux(R), похоже, использует информацию о задаче -> группе в одних местах и информацию о задаче в других, что не очень последовательно и выглядит небезопасно с точки зрения возможных ошибок.
-Каждый поток NPTL создается вызовом системного вызова `clone` с определенным набором флагов (подробнее в следующем подразделе). NPTL реализует строгую модель потоков 1:1.
+Каждый поток NPTL создается вызовом системного вызова `clone` с определённым набором флагов (подробнее в следующем подразделе). NPTL реализует строгую модель потоков 1:1.
В FreeBSD мы эмулируем потоки NPTL с помощью обычных процессов FreeBSD, которые разделяют виртуальную память и т.д., а гимнастика с PID просто имитируется в специфической для эмуляции структуре, прикреплённой к процессу. Структура, прикреплённая к процессу, выглядит следующим образом:
@@ -713,7 +713,7 @@
[[tls-i386]]
===== i386
-Загрузка TLS для текущего потока происходит путем вызова `set_thread_area`, тогда как загрузка TLS для второго процесса в `clone` выполняется в отдельном блоке в `clone`. Эти две функции очень похожи. Единственное различие заключается в фактической загрузке сегмента GDT, которая происходит при следующем переключении контекста для вновь созданного процесса, в то время как `set_thread_area` должен загрузить его напрямую. Код в основном делает следующее. Он копирует дескриптор сегмента в формате Linux(R) из пользовательского пространства. Код проверяет номер дескриптора, но поскольку он различается между FreeBSD и Linux(R), мы немного имитируем его. Мы поддерживаем только индексы 6, 3 и -1. Число 6 — это оригинальный номер Linux(R), 3 — оригинальный номер FreeBSD, а -1 означает авто-выбор. Затем мы устанавливаем номер дескриптора на константу 3 и копируем его обратно в пользовательское пространство. Мы полагаемся на то, что процесс в пользовательском пространстве использует номер из дескриптора, но это работает в большинстве случаев (никогда не встречалось ситуации, когда это не срабатывало), так как процесс в пользовательском пространстве обычно передаёт 1. Затем мы преобразуем дескриптор из формата Linux(R) в машинозависимую форму (т.е. независимую от операционной системы) и копируем его в дескриптор сегмента, определенный FreeBSD. Наконец, мы можем загрузить его. Мы назначаем дескриптор PCB потока (блок управления процессом) и загружаем сегмент `%gs` с помощью `load_gs`. Эта загрузка должна выполняться в критической секции, чтобы ничто не могло нас прервать. Случай `CLONE_SETTLS` работает точно так же, только загрузка с помощью `load_gs` не выполняется. Сегмент, используемый для этого (сегмент номер 3), разделяется между процессами FreeBSD и Linux(R), поэтому слой эмуляции Linux(R) не добавляет накладных расходов по сравнению с обычным FreeBSD.
+Загрузка TLS для текущего потока происходит путем вызова `set_thread_area`, тогда как загрузка TLS для второго процесса в `clone` выполняется в отдельном блоке в `clone`. Эти две функции очень похожи. Единственное различие заключается в фактической загрузке сегмента GDT, которая происходит при следующем переключении контекста для вновь созданного процесса, в то время как `set_thread_area` должен загрузить его напрямую. Код в основном делает следующее. Он копирует дескриптор сегмента в формате Linux(R) из пользовательского пространства. Код проверяет номер дескриптора, но поскольку он различается между FreeBSD и Linux(R), мы немного имитируем его. Мы поддерживаем только индексы 6, 3 и -1. Число 6 — это оригинальный номер Linux(R), 3 — оригинальный номер FreeBSD, а -1 означает авто-выбор. Затем мы устанавливаем номер дескриптора на константу 3 и копируем его обратно в пользовательское пространство. Мы полагаемся на то, что процесс в пользовательском пространстве использует номер из дескриптора, но это работает в большинстве случаев (никогда не встречалось ситуации, когда это не срабатывало), так как процесс в пользовательском пространстве обычно передаёт 1. Затем мы преобразуем дескриптор из формата Linux(R) в машинозависимую форму (т.е. независимую от операционной системы) и копируем его в дескриптор сегмента, определённый FreeBSD. Наконец, мы можем загрузить его. Мы назначаем дескриптор PCB потока (блок управления процессом) и загружаем сегмент `%gs` с помощью `load_gs`. Эта загрузка должна выполняться в критической секции, чтобы ничто не могло нас прервать. Случай `CLONE_SETTLS` работает точно так же, только загрузка с помощью `load_gs` не выполняется. Сегмент, используемый для этого (сегмент номер 3), разделяется между процессами FreeBSD и Linux(R), поэтому слой эмуляции Linux(R) не добавляет накладных расходов по сравнению с обычным FreeBSD.
[[tls-amd64]]
===== amd64
@@ -849,7 +849,7 @@
[[futex-sleep]]
===== futex_sleep
-Когда фьютекс ставит поток в очередь на ожидание, он создает структуру `working_proc` и помещает эту структуру в список внутри структуры futex, после чего просто выполняет man:tsleep[9] для приостановки потока. Ожидание может быть ограничено по времени. После возврата из man:tsleep[9] (поток был разбужен или истекло время ожидания) структура `working_proc` удаляется из списка и уничтожается. Все это выполняется в функции `futex_sleep`. Если мы были разбужены с помощью `futex_wake`, у нас установлен `wp_new_futex`, поэтому мы ожидаем на нем. Таким образом, фактическое перемещение выполняется в этой функции.
+Когда фьютекс ставит поток в очередь на ожидание, он создает структуру `working_proc` и помещает эту структуру в список внутри структуры futex, после чего просто выполняет man:tsleep[9] для приостановки потока. Ожидание может быть ограничено по времени. После возврата из man:tsleep[9] (поток был разбужен или истекло время ожидания) структура `working_proc` удаляется из списка и уничтожается. Все это выполняется в функции `futex_sleep`. Если мы были разбужены с помощью `futex_wake`, у нас установлен `wp_new_futex`, поэтому мы ожидаем на нём. Таким образом, фактическое перемещение выполняется в этой функции.
Постарайтесь не использовать MIME: многие используют программы, которые не очень хорошо работают с MIME.
* Проверьте правильность настроек времени и временной зоны. Это может выглядеть немножко глупо, потому что ваши сообщения все равно будут доставляться, однако многие люди получают несколько сотен сообщений в день. Зачастую они сортируют входящие сообщения по теме и дате, и если ваше сообщение не будет предшествовать первому ответу, то они могут предположить, что оно потерялось и даже не взглянут на него.
-* Основной объем информации, который вы должны предоставить, представляет собой вывод программ, таких, как man:dmesg[8], или консольные сообщения, которые обычно появляются в файле [.filename]#/var/log/messages#. Не пытайтесь скопировать эту информацию, набрав ее снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как `dmesg`, перенаправьте вывод в файл и включите его в письмо. Например,
+* Основной объём информации, который вы должны предоставить, представляет собой вывод программ, таких, как man:dmesg[8], или консольные сообщения, которые обычно появляются в файле [.filename]#/var/log/messages#. Не пытайтесь скопировать эту информацию, набрав её снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как `dmesg`, перенаправьте вывод в файл и включите его в письмо. Например,
-Мы ожидаем, что подопечные будут готовы к конструктивной критике от сообщества. Здесь еще много "преданий" и традиций, неписанных правил. Умение правильно реагировать на конструктивную критику — это то, на что мы обращаем внимание в первую очередь, оценивая вклад подопечных в IRC и в почтовых рассылках.
+Мы ожидаем, что подопечные будут готовы к конструктивной критике от сообщества. Здесь ещё много "преданий" и традиций, неписанных правил. Умение правильно реагировать на конструктивную критику — это то, на что мы обращаем внимание в первую очередь, оценивая вклад подопечных в IRC и в почтовых рассылках.
Мы предупреждаем подопечных, что часть критики может быть менее "конструктивной", чем остальная (будь то из-за проблем с языком общения или излишней придирчивости), и что умение достойно принимать такую критику — это часть участия в большом сообществе. В случае конкретных проблем с определёнными людьми или любых вопросов мы надеемся, что они обратятся к членам portmgr в IRC или по электронной почте.
-Настоятельно рекомендуется добавлять префикс `${name}` к именам всех функций, определенных в нашем скрипте, чтобы они никогда не конфликтовали с функциями из man:rc.subr[8] или другого общего включаемого файла.
+Настоятельно рекомендуется добавлять префикс `${name}` к именам всех функций, определённых в нашем скрипте, чтобы они никогда не конфликтовали с функциями из man:rc.subr[8] или другого общего включаемого файла.
====
➐ Этот вызов man:rc.subr[8] загружает переменные man:rc.conf[5]. Наш скрипт пока их не использует, но всё равно рекомендуется загружать man:rc.conf[5], потому что могут быть переменные man:rc.conf[5], управляющие самим man:rc.subr[8].
@@ -214,7 +214,7 @@
====
-➍ Теперь сообщение, отображаемое при загрузке, больше не жестко закодировано в скрипте. Оно задается переменной `dummy_msg` в man:rc.conf[5]. Это простой пример того, как переменные man:rc.conf[5] могут управлять скриптом в [.filename]#rc.d#.
+➍ Теперь сообщение, отображаемое при загрузке, больше не жёстко закодировано в скрипте. Оно задается переменной `dummy_msg` в man:rc.conf[5]. Это простой пример того, как переменные man:rc.conf[5] могут управлять скриптом в [.filename]#rc.d#.
[IMPORTANT]
====
@@ -450,7 +450,7 @@
Помимо использования специальных строк man:rcorder[8], скрипт может настаивать на своей зависимости от другой службы, просто принудительно запуская её. Это может быть необходимо, когда другая служба является опциональной и не запускается самостоятельно, потому что системный администратор ошибочно отключил её в man:rc.conf[5].
-С учетом этих общих знаний рассмотрим простой скрипт демона, дополненный зависимостями:
+С учётом этих общих знаний рассмотрим простой скрипт демона, дополненный зависимостями:
[.programlisting]
....
@@ -761,7 +761,7 @@
# service dummy_foo start
....
-Вышеприведенное создает экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [.filename]#/var/run/dummy/dummy.pid#.
+Вышеприведённое создает экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [.filename]#/var/run/dummy/dummy.pid#.
Сервисы dummy и dummy_foo могут управляться независимо друг от друга, при этом скрипт запуска обновляется автоматически при обновлении пакета (благодаря символьной ссылке). Это не обновляет строку REQUIRE, поэтому нет простого способа зависеть от конкретного экземпляра. Чтобы зависеть от конкретного экземпляра в порядке запуска, необходимо создать копию вместо использования символьной ссылки. Это предотвращает автоматическое применение изменений в скрипте запуска при установке обновления.
-Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion footnote:[Subversion, http://subversion.apache.org] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право записи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти extref:{contributors}[коммиттеры FreeBSD, staff-committers]footnote:[extref:{contributors}[коммиттеры FreeBSD, staff-committers]] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Избранная группа разработчиков — link:https://www.FreeBSD.org/administration/#t-core[Core Team]footnote:[link:https://www.FreeBSD.org/administration/#t-core[Core Team FreeBSD]] — обеспечивает некоторый уровень руководства проектом.
+Разработка FreeBSD — это очень открытый процесс. FreeBSD создается благодаря вкладу тысяч людей по всему миру. Проект FreeBSD предоставляет доступ к Subversion footnote:[Subversion, http://subversion.apache.org] для широкой публики, чтобы другие могли просматривать сообщения журнала, различия (патчи) между ветками разработки и другие улучшения производительности, которые предоставляет система управления исходным кодом. Это значительно помогло привлечь больше талантливых разработчиков в FreeBSD. Однако, я думаю, все согласятся, что хаос быстро воцарился бы, если бы право записи в основной репозиторий было открыто для всех в Интернете. Поэтому только «избранная» группа из почти 300 человек имеет право записи в репозиторий Subversion. Эти extref:{contributors}[коммиттеры FreeBSD, staff-committers]footnote:[extref:{contributors}[коммиттеры FreeBSD, staff-committers]] обычно являются людьми, которые выполняют основную часть разработки FreeBSD. Выбранная группа разработчиков — link:https://www.FreeBSD.org/administration/#t-core[Основная команда (Core Team)]footnote:[link:https://www.FreeBSD.org/administration/#t-core[Основная команда FreeBSD]] — обеспечивает некоторый уровень руководства проектом.
Быстрый темп разработки `FreeBSD` делает основную ветку разработки непригодной для повседневного использования широкой публикой. В частности, требуются усилия по стабилизации для доведения системы разработки до релиза производственного качества. Для решения этого конфликта разработка продолжается по нескольким параллельным направлениям. Основная ветка разработки — это _HEAD_ или _trunk_ нашего дерева Subversion, известная как "FreeBSD-CURRENT" или сокращённо "-CURRENT".
@@ -115,7 +115,7 @@
Вскоре после начала заморозки кода создаётся образ _BETA1_ и выпускается для широкого тестирования. В период заморозки кода не реже чем раз в две недели выпускается как минимум один бета-образ или кандидат в релизы, пока не будет готов финальный выпуск. В дни, предшествующие финальному релизу, команда разработки выпусков постоянно взаимодействует с командой security-officer, сопровождающими документации и сопровождающими портов, чтобы убедиться, что все необходимые компоненты для успешного релиза доступны.
-После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создается ветка релиза, и образы _Release Candidate_ (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жесткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности.
+После того, как качество BETA-образов становится достаточно удовлетворительным и не планируется крупных и потенциально рискованных изменений, создается ветка релиза, и образы _Release Candidate_ (RC) собираются из ветки релиза, вместо BETA-образов из ветки STABLE. Также снимается заморозка изменений в ветке STABLE, а ветка релиза переходит в режим "жёсткой заморозки кода", когда становится значительно сложнее обосновать новые изменения в системе, за исключением исправления серьезных ошибок или проблем безопасности.
-В Sysinstall следует добавить информацию о количестве доступных портов и объеме дискового пространства, необходимого для коллекции портов. footnote:[Коллекция портов FreeBSD https://ports.FreeBSD.org] В настоящее время эта информация хранится в [.filename]#src/usr.sbin/bsdinstall/dist.c#.
+В Sysinstall следует добавить информацию о количестве доступных портов и объёме дискового пространства, необходимого для коллекции портов. footnote:[Коллекция портов FreeBSD https://ports.FreeBSD.org] В настоящее время эта информация хранится в [.filename]#src/usr.sbin/bsdinstall/dist.c#.
После сборки выпуска следует обновить ряд файлов, чтобы объявить о выпуске. Эти файлы находятся относительно `head/` в поддереве `doc/` Subversion.
Система mfsBSD успешно загружена, и теперь можно войти через man:ssh[1]. В этом разделе будет описано, как создавать и размечать разделы, настраивать `gmirror` для RAID-1, а также как использовать `sysinstall` для установки минимальной дистрибуции операционной системы FreeBSD.
-=== Подготовка жестких дисков
+=== Подготовка жёстких дисков
Первая задача — выделить дисковое пространство для FreeBSD, т.е.: создать слайсы и разделы. Очевидно, что текущая работающая система полностью загружена в оперативную память, поэтому не будет проблем с манипуляциями жёсткими дисками. Для выполнения этой задачи можно использовать либо `sysinstall`, либо man:fdisk[8] в сочетании с man:bsdlabel[8].
@@ -226,13 +226,13 @@
# newfs /dev/mirror/usr
....
-<.> Создайте раздел, охватывающий весь диск, и инициализируйте загрузочный код, содержащийся в секторе 0 данного диска. Повторите эту команду для всех жестких дисков в системе.
+<.> Создайте раздел, охватывающий весь диск, и инициализируйте загрузочный код, содержащийся в секторе 0 данного диска. Повторите эту команду для всех жёстких дисков в системе.
<.> Запишите стандартную метку для каждого диска, включая загрузочный код.
<.> Теперь вручную отредактируйте метку указанного диска. Обратитесь к странице руководства man:bsdlabel[8], чтобы узнать, как создавать разделы. Создайте раздел `a` для [.filename]#/# — корневой файловой системы, `b` для раздела подкачки, `d` для [.filename]#/var#, `e` для [.filename]#/usr# и, наконец, `f`, который позже будет использоваться для ZFS.
-<.> Импортируйте только что созданную метку для второго жесткого диска, чтобы оба жестких диска были размечены одинаковым образом.
+<.> Импортируйте только что созданную метку для второго жёсткого диска, чтобы оба жёстких диска были размечены одинаковым образом.
<.> Инициализируйте man:gmirror[8] на каждом разделе.
@@ -272,7 +272,7 @@
=== Шаги после установки
-Операционная система FreeBSD теперь должна быть установлена; однако процесс еще не завершен. Необходимо выполнить несколько шагов после установки, чтобы FreeBSD могла загружаться в будущем и чтобы можно было войти в систему.
+Операционная система FreeBSD теперь должна быть установлена; однако процесс ещё не завершен. Необходимо выполнить несколько шагов после установки, чтобы FreeBSD могла загружаться в будущем и чтобы можно было войти в систему.
Вы должны теперь выполнить man:chroot[8] в только что установленную систему, чтобы завершить установку. Используйте следующую команду: