git: 41ee84e60e - main - update translation of books/design-44bsd to Russian Reviewed by: andy Differential Revision: https://reviews.freebsd.org/D53740

Vladlen Popolitov <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.doc
Message-ID <[email protected]> 
The branch main has been updated by vladlen:

URL: https://cgit.FreeBSD.org/doc/commit/?id=41ee84e60e81eca480785485426f00e17289c65a

commit 41ee84e60e81eca480785485426f00e17289c65a
Author:     Vladlen Popolitov <[email protected]>
AuthorDate: 2025-11-18 18:16:43 +0000
Commit:     Vladlen Popolitov <[email protected]>
CommitDate: 2025-11-18 18:18:16 +0000

    update translation of books/design-44bsd to Russian
    Reviewed by: andy
    Differential Revision: https://reviews.freebsd.org/D53740
---
 .../content/ru/books/design-44bsd/_index.adoc        | 20 ++++++++++----------
 .../content/ru/books/design-44bsd/_index.po          | 20 ++++++++++----------
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/documentation/content/ru/books/design-44bsd/_index.adoc b/documentation/content/ru/books/design-44bsd/_index.adoc
index 1e07c9a701..676c9183dd 100644
--- a/documentation/content/ru/books/design-44bsd/_index.adoc
+++ b/documentation/content/ru/books/design-44bsd/_index.adoc
@@ -111,7 +111,7 @@ _Ядро_, по традиционной терминологии операц
 |универсальные интерфейсы |4,782 |2.4
 |межпроцессное взаимодействие |4,540 |2.2
 |работа с терминалом |3,911 |1.9
-|Виртуальная память |11,813 |5.8
+|виртуальная память |11,813 |5.8
 |управление vnode |7,954 |3.9
 |имена в файловой системы |6,550 |3.2
 |быстрое хранилище файлов |4,365 |2.2
@@ -145,7 +145,7 @@ _Ядро_, по традиционной терминологии операц
 |заголовочные файлы, зависимые от машины |1,562 |0.8
 |заголовочные файлы драйверов устройств |3,495 |1.7
 |исходный код драйверов устройств |17,506 |8.7
-|Виртуальная память |3,087 |1.5
+|виртуальная память |3,087 |1.5
 |код, зависящий от других машин |6,287 |3.1
 |подпрограммы на языке ассемблера |3,014 |1.5
 |совместимость с HP/UX |4,683 |2.3
@@ -230,7 +230,7 @@ image:fig1.png[Жизненный цикл процесса]
 
 Попытки постепенно усовершенствовать старую реализацию заведомо были обречены на неудачу. Полностью новая архитектура, с другой стороны, могла бы использовать большие объемы памяти, уменьшить дисковые операции и обеспечивать работу с несколькими процессорами. Наконец, система виртуальной памяти в 4.4BSD была полностью изменена. Система виртуальной памяти 4.4BSD основана на системе виртуальной памяти (VM) crossref:design-44bsd[biblio-tevanian, [Tevanian, 1987]]
  с заимствованиями из Mach 2.5 и Mach 3.0. В ней была эффективная поддержка совместного использования, полное р
азделение машинозависимой и машинонезависимой частей, а также (сейчас не используемая) поддержка работы с несколькими процессорами. Процессы могут отображать файлы в любую область своего адресного пространства. Они могут совместно использовать части своих адресных пространств посредством отображения в память одного и того же файла. Изменения, сделанные одним процессом, видны в адресном пространстве другого процесса, а также запÐ
 ¸ÑÑ‹Ð²Ð°ÑŽÑ‚ся и в сам файл. Процессы могут также запрашивать эксклюзивное отображение файла в память, при кÐ
¾Ñ‚ором любые изменения, сделанные процессом, не видны другим процессам, которые отображают файл в память и не записываются обратно в файл.
 
-Еще одной проблемой с системой виртуальной памяти является способ, которым информация передается ядру при выполнении системного вызова. 4.4BSD всегда копирует данные из адресного пространства процесса в буфер ядра. Для операций чтения и записи, при которых передаются большие объемы данных, выполнение копирования может оказаться занимающим время процессом. Альтернативным способом является манипуляции с адресным пространством проц
 есса в ядре. Ядро 4.4BSD всегда копирует данные о нескольким причинам:
+Еще одной проблемой с системой виртуальной памяти является способ, которым информация передаётся ядру при выполнении системного вызова. 4.4BSD всегда копирует данные из адресного пространства процесса в буфер ядра. Для операций чтения и записи, при которых передаются большие объемы данных, выполнение копирования может оказаться занимающим время процессом. Альтернативным способом является манипуляции с адресным пространством проц
 есса в ядре. Ядро 4.4BSD всегда копирует данные о нескольким причинам:
 
 * Зачастую пользовательские данные не выравнены по границе страницы памяти и их объем не кратен размеру аппаратной страницы памяти.
 * Если страница памяти забирается от процесса, он не может больше ссылаться на эту страницу. Некоторые программы зависят от данных, остающихся в буфере, даже после записи этих данных.
@@ -243,7 +243,7 @@ image:fig1.png[Жизненный цикл процесса]
 
 Ядро часто выполняет выделение памяти, которое нужно только для выполнения единственного системного вызова. В пользовательском процессе такая кратковременно используемая память будет выделяться в стеке во время выполнения. Так как ядро имеет ограниченный объем стека времени выполнения, то неэффективно выделять в нем даже блоки памяти среднего размера. Таким образом, такая память должна выделяться посредством более гибкого меха
 низма. Например, когда системный вызов должен преобразовать имя каталога, он должен выделить буфер разÐ
¼ÐµÑ€Ð¾Ð¼ 1 Кбайт для хранения имени. Другие блоки памяти должны выделяться на более продолжительный срок, чем один системный вызов, и поэтому не могут выделяться в стеке, даже если там есть место. В качестве примера можно взять блоки управления протоколами, которые существуют на всем протяжении сетевого соединения.
 
-Необходимость в динамическом выделении памяти в ядре становилась все более острой вместе с добавлением количества сервисов. Общий механизм выделения памяти уменьшает сложность написания кода в ядре. Поэтому в 4.4BSD ядро имеет единый механизм выделения памяти, который может использоваться в любой части системы. У него есть интерфейс, похожий на функции библиотеки языка C _malloc_ и _free_, которые обеспечивают выделение памяти в прикладных
  программах crossref:design-44bsd[biblio-mckusick-2, [McKusick & Karels, 1988]]. Как интерфейс библиотеки языка C, функция выделения пÐ
°Ð¼ÑÑ‚и получает параметр, указывающий на размер памяти, который необходим. Диапазон запрашиваемых объемов выделяемой памяти не ограничен; однако выделяемая физическая память не подвергается постраничной подгрузке. Функции освобождения памяти передается указатель на освобождаемый участок памяти, но указывать размер освобождаемого участка памяти не нужно.
+Необходимость в динамическом выделении памяти в ядре становилась все более острой вместе с добавлением количества сервисов. Общий механизм выделения памяти уменьшает сложность написания кода в ядре. Поэтому в 4.4BSD ядро имеет единый механизм выделения памяти, который может использоваться в любой части системы. У него есть интерфейс, похожий на функции библиотеки языка C _malloc_ и _free_, которые обеспечивают выделение памяти в прикладных
  программах crossref:design-44bsd[biblio-mckusick-2, [McKusick & Karels, 1988]]. Как интерфейс библиотеки языка C, функция выделения пÐ
°Ð¼ÑÑ‚и получает параметр, указывающий на размер памяти, который необходим. Диапазон запрашиваемых объемов выделяемой памяти не ограничен; однако выделяемая физическая память не подвергается постраничной подгрузке. Функции освобождения памяти передаётся указатель на освобождаемый участок памяти, но указывать размер освобождаемого участка памяти не нужно.
 
 [[overview-io-system]]
 === Система ввода/вывода
@@ -260,7 +260,7 @@ image:fig1.png[Жизненный цикл процесса]
 
 * _Файл_ представляет собой линейную последовательность байт, имеющую по крайней мере одно имя. Файл существует, пока все его имена не удалены и ни один из процессов не хранит его дескриптор. Процесс получает дескриптор файла, открывая имя файла посредством системного вызова _open_. Работа с устройствами ввода/вывода осуществляется как с файлами.
 * _Каналом_ является линейная последовательность байт, такая же, как файл, но используемая исключительно как поток ввода/вывода, причем однонаправленный. У канала нет имени, и поэтому он не может быть открыт при помощи _open_. Вместо этого он создается посредством системного вызова _pipe_, который возвращает два дескриптора, один из которых принимает входные данные, без искажений, без повторений и в той же самой последовательности посылаем
 ый на другой дескриптор. Система также поддерживает именованный канал, или FIFO. FIFO имеет те же самые свой
ства, что и канал, за исключением того, что он располагается в файловой системе; поэтому он может быть открыт системным вызовом _open_. Процессы, которые хотят обмениваться данными, открывают FIFO: Один процесс открывает его для чтения, а другой для записи.
-* _Сокет_ является промежуточным объектом, который используется для межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит дескриптор, ссылающийся на него. Сокет создается системным вызовом _socket_, который возвращает его дескриптор. Имеется несколько типов сокетов, которые поддерживают различные коммуникационные возможности, такие, как надежную доставку данных, сохранение последовательности передаваемых сообще
 ний, и сохранение границ сообщений.
+* _Сокет_ является промежуточным объектом, который используется для межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит дескриптор, ссылающийся на него. Сокет создается системным вызовом _socket_, который возвращает его дескриптор. Имеется несколько типов сокетов, которые поддерживают различные коммуникационные возможности, такие, как надёжную доставку данных, сохранение последовательности передаваемых сообще
 ний, и сохранение границ сообщений.
 
 В системах, предшествующих 4.2BSD, каналы были реализованы в файловой системе, когда в 4.2BSD появились сокеты, то каналы были повторно реализованы как сокеты.
 
@@ -296,7 +296,7 @@ image:fig1.png[Жизненный цикл процесса]
 
 ==== Механизм межпроцессных коммуникаций посредством сокетов
 
-В ядре 4.2BSD появился механизм межпроцессного взаимодействия, более гибкий, чем каналы, основанный на _сокетах_. Сокет является конечной точкой коммуникаций, доступный через дескриптор, как файл или канал. Каждый из двух процессов может создать сокет, а затем соединить эти конечные точки для получения надежного канала передачи потока байт. После соединения процесс может выполнять с дескрипторами операции чтения и записи, как это дела
 лось с каналами. Прозрачность сокетов позволяет ядру перенаправить вывод одного процесса на вход другÐ
¾Ð³Ð¾, работающего на другой машине. Большим различием между каналами и сокетами является то, что каналы требуют наличия общего родительского процесса для установки коммуникации. Соединение между сокетами может быть установлено двумя несвязанными процессами, возможно, работающими на разных машинах.
+В ядре 4.2BSD появился механизм межпроцессного взаимодействия, более гибкий, чем каналы, основанный на _сокетах_. Сокет является конечной точкой коммуникаций, доступный через дескриптор, как файл или канал. Каждый из двух процессов может создать сокет, а затем соединить эти конечные точки для получения надёжного канала передачи потока байт. После соединения процесс может выполнять с дескрипторами операции чтения и записи, как это дела
 лось с каналами. Прозрачность сокетов позволяет ядру перенаправить вывод одного процесса на вход другÐ
¾Ð³Ð¾, работающего на другой машине. Большим различием между каналами и сокетами является то, что каналы требуют наличия общего родительского процесса для установки коммуникации. Соединение между сокетами может быть установлено двумя несвязанными процессами, возможно, работающими на разных машинах.
 
 System V предоставляет механизм локального межпроцессного взаимодействия через FIFO (также называемые _именованными каналами_). FIFO отображаются как объекты файловой системы, которые могут быть открыты несвязанными процессами, и в которые можно открывать и посылать данные так же, как в случае каналов. Таким образом, FIFO не требуют общего родительского процесса для установки соединения; они могут быть соединены после того, как будут запуще
 ны два процесса. В отличие от сокетов, FIFO могут быть использованы только на локальной машине; они не могÑ
ƒÑ‚ быть использованы для связи между процессами, работающими на разных машинах. FIFO реализованы в 4.4BSD, потому что это требует стандарт POSIX.1. Их функциональность является подмножеством функций интерфейса сокетов.
 
@@ -304,7 +304,7 @@ System V предоставляет механизм локального меж
 
 ==== Множественный ввод/вывод
 
-Кроме традиционных системных вызовов _read_ и _write_, в 4.2BSD появилась возможность выполнять множественный ввод/вывод. Множественный ввод использует системный вызов _readv_ для размещения результата единственной операции чтения в нескольких различных буферах. Обратно, системный вызов _writev_ позволяет осуществлять запись нескольких различных буферов за одну атомарную операцию записи. Вместо передачи одного буфера и его длины в качестве паÑ
 €Ð°Ð¼ÐµÑ‚ров, как это делается при использовании системных вызовов _read_ и _write_, процесс передает указатель нÐ
° массив буферов и их длин, а также счетчик, определяющий размер массива.
+Кроме традиционных системных вызовов _read_ и _write_, в 4.2BSD появилась возможность выполнять множественный ввод/вывод. Множественный ввод использует системный вызов _readv_ для размещения результата единственной операции чтения в нескольких различных буферах. Обратно, системный вызов _writev_ позволяет осуществлять запись нескольких различных буферов за одну атомарную операцию записи. Вместо передачи одного буфера и его длины в качестве паÑ
 €Ð°Ð¼ÐµÑ‚ров, как это делается при использовании системных вызовов _read_ и _write_, процесс передаёт указатель нÐ
° массив буферов и их длин, а также счетчик, определяющий размер массива.
 
 Такой механизм позволяет буферам в различных областях адресного пространства процесса записываться атомарно, без необходимости копировать их в один буфер. Атомарные операции записи необходимы в случае, когда низкоуровневые абстракции основаны на записях, например, стримеры, которые выводят блок ленты при каждом запросе на запись. Также полезна возможность помещать результат одного запроса на чтение в нескольких различных буфер
 ах (например, заголовок записи в одно место, а данные в другое). Хотя приложение может симулировать возмÐ
¾Ð¶Ð½Ð¾ÑÑ‚ÑŒ выполнять множественные операции посредством чтения данных в большой буфер с последующим копированием их частей в нужные области, и накладные расходы на копирование в памяти в таких случаях часто увеличивает время выполнения приложения чуть ли не вдвое.
 
@@ -411,11 +411,11 @@ image:fig2.png[Дерево небольшой файловой системы]
 [[overview-terminal]]
 === Терминалы
 
-Терминалы поддерживают стандартные системные операции ввода/вывода, а также набор операций, специфичных для терминалов, для управления редактированием входных символов и задержек вывода. На самом нижнем уровне находятся драйверы терминальных устройств, которые управляют портами аппаратных терминалов. Терминальный ввод обрабатывается согласно низлежащим характеристикам связи, таким, как скорость передачи, и согласно набору прÐ
 ¾Ð³Ñ€Ð°Ð¼Ð¼Ð½Ð¾ контролируемых параметров, таких, как контроль четности.
+Терминалы поддерживают стандартные системные операции ввода/вывода, а также набор операций, специфичных для терминалов, для управления редактированием входных символов и задержек вывода. На самом нижнем уровне находятся драйверы терминальных устройств, которые управляют портами аппаратных терминалов. Терминальный ввод обрабатывается согласно низлежащим характеристикам связи, таким, как скорость передачи, и согласно набору прÐ
 ¾Ð³Ñ€Ð°Ð¼Ð¼Ð½Ð¾ контролируемых параметров, таких, как контроль чётности.
 
 Выше уровня драйверов терминальных устройств находятся режимы каналов, которые обеспечивают различные уровни обработки символов. По умолчанию режим работы канала выбирается, когда порт используется для интерактивного входа в систему. Режим работы канала устанавливается в _канонический_; входной поток обрабатывается так, что обеспечиваются стандартные функции, ориентированные на редактирование строк, и он представляется процес
 су в виде целых строк.
 
-Экранные редакторы и программы, которые взаимодействуют с другими машинами, обычно работают в _неканоническом режиме_ (часто называемом _raw-режимом_ или _посимвольным режимом_). В этом режиме входной поток передается в читающий процесс сразу же и без всякой обработки. Выключается вся обработка специальных символов, не выполняется удаление символов и другое редактирование строк, все символы передаются программе, которая выполняет чт
 ение с терминала.
+Экранные редакторы и программы, которые взаимодействуют с другими машинами, обычно работают в _неканоническом режиме_ (часто называемом _raw-режимом_ или _посимвольным режимом_). В этом режиме входной поток передаётся в читающий процесс сразу же и без всякой обработки. Выключается вся обработка специальных символов, не выполняется удаление символов и другое редактирование строк, все символы передаются программе, которая выполняет чт
 ение с терминала.
 
 Терминал может быть настроен тысячами различных способов, промежуточных между этими двумя. Например, экранный редактор, которому необходимо получать прерывания от пользователя асинхронно, может разрешить использование специальных символов, которые генерируют сигналы и разрешить управление выходным потоком, в противном случае работать в неканоническом режиме; все остальные символы будут передаваться в процесс необработанными.
 
 
@@ -433,7 +433,7 @@ image:fig2.png[Дерево небольшой файловой системы]
 
 Межпроцессные коммуникации в 4.4BSD организованы в _коммуникационные домены_. К поддерживаемым на данный момент доменам относятся _локальный домен_ для взаимодействия между процессами, выполняющимися на одной и той же машине; _межсетевой домен_ для связи между процессами посредством набора протоколов TCP/IP (возможно, в сети Интернет); семейство протоколов ISO/OSI для взаимодействия между сайтами, которым нужна именно такая связь, и _домен XN
 S_ для коммуникаций между процессами при помощи протоколов XEROX Network Systems (XNS).
 
-В пределах домена соединения имеют место между конечными точками связи, также называемыми _сокетами_. Как отмечено в Разделе 2.6, системный вызов _socket_ создает сокет и возвращает дескриптор; другие системные вызовы IPC описаны в Главе 11. Каждый сокет имеет тип, определяющий его коммуникационные свойства; к ним относятся такие характеристики, как надежность, сохранение последовательности передаваемой информации и предупреждение дублиÑ
 €Ð¾Ð²Ð°Ð½Ð¸Ñ сообщений.
+В пределах домена соединения имеют место между конечными точками связи, также называемыми _сокетами_. Как отмечено в Разделе 2.6, системный вызов _socket_ создает сокет и возвращает дескриптор; другие системные вызовы IPC описаны в Главе 11. Каждый сокет имеет тип, определяющий его коммуникационные свойства; к ним относятся такие характеристики, как надёжность, сохранение последовательности передаваемой информации и предупреждение дублиÑ
 €Ð¾Ð²Ð°Ð½Ð¸Ñ сообщений.
 
 с каждым сокетом связан некоторый _коммуникационный протокол_. Этот протокол обеспечивает выполнение операций, требуемых сокету, согласно его типу. Приложения могут задавать нужный протокол при создании сокета или могут разрешить системе выбрать протокол, который соответствует типу создаваемого сокета.
 
diff --git a/documentation/content/ru/books/design-44bsd/_index.po b/documentation/content/ru/books/design-44bsd/_index.po
index 8887737e67..d88b35bc4a 100644
--- a/documentation/content/ru/books/design-44bsd/_index.po
+++ b/documentation/content/ru/books/design-44bsd/_index.po
@@ -6,7 +6,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: FreeBSD Documentation VERSION\n"
 "POT-Creation-Date: 2024-12-29 08:29-0500\n"
-"PO-Revision-Date: 2025-10-29 04:45+0000\n"
+"PO-Revision-Date: 2025-11-13 04:45+0000\n"
 "Last-Translator: Vladlen Popolitov <[email protected]>\n"
 "Language-Team: Russian <https://translate-dev.freebsd.org/projects/"
 "documentation/booksdesign-44bsd_index/ru/>\n"
@@ -496,7 +496,7 @@ msgstr "1.9"
 #: documentation/content/en/books/design-44bsd/_index.adoc:169
 #, no-wrap
 msgid "virtual memory"
-msgstr "Виртуальная память"
+msgstr "виртуальная память"
 
 #. type: Table
 #: documentation/content/en/books/design-44bsd/_index.adoc:132
@@ -1630,7 +1630,7 @@ msgid ""
 "the data for several reasons:"
 msgstr ""
 "Еще одной проблемой с системой виртуальной памяти является способ, которым "
-"информация передается ядру при выполнении системного вызова. 4.4BSD всегда "
+"информация передаётся ядру при выполнении системного вызова. 4.4BSD всегда "
 "копирует данные из адресного пространства процесса в буфер ядра. Для "
 "операций чтения и записи, при которых передаются большие объемы данных, "
 "выполнение копирования может оказаться занимающим время процессом. "
@@ -1763,7 +1763,7 @@ msgstr ""
 "параметр, указывающий на размер памяти, который необходим. Диапазон "
 "запрашиваемых объемов выделяемой памяти не ограничен; однако выделяемая "
 "физическая память не подвергается постраничной подгрузке. Функции "
-"освобождения памяти передается указатель на освобождаемый участок памяти, но "
+"освобождения памяти передаётся указатель на освобождаемый участок памяти, но "
 "указывать размер освобождаемого участка памяти не нужно."
 
 #. type: Title ===
@@ -1909,7 +1909,7 @@ msgstr ""
 "межпроцессных коммуникаций; он существует, пока какой-либо процесс хранит "
 "дескриптор, ссылающийся на него. Сокет создается системным вызовом _socket_, "
 "который возвращает его дескриптор. Имеется несколько типов сокетов, которые "
-"поддерживают различные коммуникационные возможности, такие, как надежную "
+"поддерживают различные коммуникационные возможности, такие, как надёжную "
 "доставку данных, сохранение последовательности передаваемых сообщений, и "
 "сохранение границ сообщений."
 
@@ -2222,7 +2222,7 @@ msgstr ""
 "чем каналы, основанный на _сокетах_. Сокет является конечной точкой "
 "коммуникаций, доступный через дескриптор, как файл или канал. Каждый из двух "
 "процессов может создать сокет, а затем соединить эти конечные точки для "
-"получения надежного канала передачи потока байт. После соединения процесс "
+"получения надёжного канала передачи потока байт. После соединения процесс "
 "может выполнять с дескрипторами операции чтения и записи, как это делалось с "
 "каналами. Прозрачность сокетов позволяет ядру перенаправить вывод одного "
 "процесса на вход другого, работающего на другой машине. Большим различием "
@@ -2313,7 +2313,7 @@ msgstr ""
 "_writev_ позволяет осуществлять запись нескольких различных буферов за одну "
 "атомарную операцию записи. Вместо передачи одного буфера и его длины в "
 "качестве параметров, как это делается при использовании системных вызовов "
-"_read_ и _write_, процесс передает указатель на массив буферов и их длин, а "
+"_read_ и _write_, процесс передаёт указатель на массив буферов и их длин, а "
 "также счетчик, определяющий размер массива."
 
 #. type: Plain text
@@ -3125,7 +3125,7 @@ msgstr ""
 "драйверы терминальных устройств, которые управляют портами аппаратных "
 "терминалов. Терминальный ввод обрабатывается согласно низлежащим "
 "характеристикам связи, таким, как скорость передачи, и согласно набору "
-"программно контролируемых параметров, таких, как контроль четности."
+"программно контролируемых параметров, таких, как контроль чётности."
 
 #. type: Plain text
 #: documentation/content/en/books/design-44bsd/_index.adoc:740
@@ -3157,7 +3157,7 @@ msgid ""
 msgstr ""
 "Экранные редакторы и программы, которые взаимодействуют с другими машинами, "
 "обычно работают в _неканоническом режиме_ (часто называемом _raw-режимом_ "
-"или _посимвольным режимом_). В этом режиме входной поток передается в "
+"или _посимвольным режимом_). В этом режиме входной поток передаётся в "
 "читающий процесс сразу же и без всякой обработки. Выключается вся обработка "
 "специальных символов, не выполняется удаление символов и другое "
 "редактирование строк, все символы передаются программе, которая выполняет "
@@ -3270,7 +3270,7 @@ msgstr ""
 "_socket_ создает сокет и возвращает дескриптор; другие системные вызовы IPC "
 "описаны в Главе 11. Каждый сокет имеет тип, определяющий его "
 "коммуникационные свойства; к ним относятся такие характеристики, как "
-"надежность, сохранение последовательности передаваемой информации и "
+"надёжность, сохранение последовательности передаваемой информации и "
 "предупреждение дублирования сообщений."
 
 #. type: Plain text
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.