Независимо от причины, любые попытки разжигания национальной розни (включая намеки) следует сразу пресекать.
В запущенных случаях можно посоветовать способ, к которому автор прибег при возникновении флейма на национальной почве в SPB.GENERAL (2001 год). Дополнительно к наказаниям за конкретные письма, в эхе был объявлен запрет (несколько месяцев) на любое обсуждение национальностей, наций, народностей, этносов, рас.
Для тех модераторов, которые сами плохо относятся к каким-либо национальностям,
замечу следующее:
Вы, конечно, можете оставаться при своем мнении. Но если конструктивные
разговоры и порядок в эхе для вас не пустой звук - держите свои взгляды при
себе. Любая пристрастность при назначении наказаний, намеки в обычных письмах,
будут неизбежно провоцировать флейм и снижать ваш авторитет, а, следовательно, и
возможность эффективно модерировать эху. Кроме того, допуская разговоры,
нарушающие законодательство, вы, возможно, идете на конфликт с
правоохранительными органами.
Частыми в FidoNet (и не только) являются споры-сравнения по принципу "Какая
операционная система лучше", "Какой язык программирования лучше", "Какой
микропроцессор лучше", "Какая платформа лучше" и т.п.
Хотя иногда такие споры бывают конструктивными, чаще всего они быстро
перерастают в "религиозные войны", где аргументы не принимаются во внимание, но,
тем не менее, приводятся снова и снова. Характерно, что такой спор провоцирует
очень многих и быстро начинает составлять большую часть трафика эхи.
Для модератора важно вовремя пресечь такого рода флейм # или перевести его в конструктивное русло. Обычно тему необходимо закрыть, когда беседа пошла по кругу - то есть, стали приводиться аргументы уже прозвучавшие ранее.
Если тема особо популярна (как, например, тема сравнения операционных систем в
период борьбы между MS Windows 95 и IBM OS/2), возникают эхи специально для
такого рода споров (RU.OS.CMP).
Можно упомянуть в связи с этим "правило Nebbe" из comp.lang.ada FAQ:
"Если Вы не в состоянии придумать хоть одну область, где другая ОС будет более
применима, нежели Ваша любимая, вы, вероятно, плохо в ней разбираетесь".
Другим способом снизить вероятность возникновения флейма и его объем является добавление в FAQ эхи пунктов, объективно разъясняющих преимущества и недостатки обсуждаемого продукта (иными словами - аргументы, которые приводились в спорах наиболее часто и ответы на них).
При ответе на письмо его текст становится цитатой - автоматически выделяется "квотингом" (quoting). Для этого в почтовых редакторах FidoNet принято использовать символ ">", перед которым часто указываются инициалы автора. Например:
AB> текст
Редактор автоматически подсвечивает (или иным образом выделяет) такие строки.
Недопустимо излишнее цитирование (оверквотинг - overquoting). От письма, на которое вы отвечаете, нужно оставлять только строки, необходимые для понимания смысла. Цитирование служебной информации (клуджи, origin) и приветствия, подписи так же, как правило, недопустимо.
Не рекомендуется использовать выделение квотингом в собственных письмах. Это затрудняет чтение, поскольку люди или отвлекаются на яркие вставки или воспринимают их как текст первоначального письма. Особенно распространено такое явление в эхах, предназначенных для объявлений о купле/продаже. Исключением являются письма модератора, в тех случаях, когда он хочет привлечь внимание к некоторым пунктам правил или важному объявлению.
Полное отсутствие цитирования при ответе на письмо также нежелательно.
Так как большинство почтовых редакторов работает в режиме 80 столбцов, для корректного цитирования правая граница текста не должна быть больше 75 символов.
Помимо текста и служебной информации, которая обрабатывается лишь программным обеспечением, почти любое письмо содержит также:
- Приветствие;
- Подпись;
- Дополнительную информацию;
- Tearline;
- Origin.
В Tearline обычно указывается название и версия почтового редактора, а в Origin - название станции и адрес, соответствующий полю From: письма. Однако, часто в эти поля заносится произвольная информация (кроме адреса в конце строки Origin).
В понятие "дополнительная информация" входят различные случайные строчки (куки), перечисление адресов и других персональных данных, Geek code, Fingerprint. Обычно это не приветствуется модераторами.
Также иногда можно видеть строчки [Team XXX] или [XXX], где XXX - название любимой автором письма операционной системы, музыкальной группы, автомашины, футбольной команды и т.п. Как правило, эта строчка отражает исключительно личные привязанности автора и никакой "команды" на самом деле не существует. Эта традиция изначально пошла от Team OS/2 - маркетингового приема IBM.
Общепринято, чтобы приветствие не превышало одной-двух строк, подпись (включая всевозможные куки, team'ы и т.п.) - трех строк, Tearline - 35 символов (включая "--- "), Origin - 79 символов (включая "* Origin " и адрес) #.
Еще можно упомянуть использование клуджей собственного изготовления (которые обычно не показываются при чтении писем). Это всевозможные @REALNAME, @EMAIL, а также Geek code (не приветствуется многими модераторами).
Рассмотрим вопрос соответствия имени указанного подписчиком во From: его
настоящему имени. У модераторов есть разные точки зрения на эту проблему
#.
Например, в эхах типа RU.HACKER, RU.SEX (то есть там, где требование показать
настоящее имя может мешать человеку полноценно участвовать в разговоре) логично
разрешать псевдонимы.
В других случаях - например, в эхах связанных с продажей/покупкой (как
мелкой/частной, так и коммерческой), предоставлением услуг - логично требовать
указание настоящего имени, чтобы люди могли более или менее достоверно знать, с
кем именно они вступают в сделку.
Как же отличить настоящее имя (RealName) от псевдонима (alias, nick, handle)?
Разница между псевдонимом и RealName часто определяется по нодлистовому
(поинтлистовому) имени. То есть, если человек пишет во From: 'Cobra' - это
следует расценивать как псевдоним, если в нодлисте у него написано 'Ivan
Sidorov', и как RealName, если в нодлисте написано тоже 'Cobra'.
Таким образом, модератор избавляется от необходимости проверять достоверность
реального имени (что, как правило, невозможно), условно перекладывая
ответственность на узел-босс (если речь идет об имени поинта) или NC, RC (если
речь об имени узла), которые принимают решение о включении в нодлист/поинтлист
соответствующей строчки.
Если речь идет о пользователях BBS или гейта, то здесь ответственность за соответствие имени ложится на сисопа BBS, или на гейтмастера.
В отдельных случаях модератор может требовать реального имени не на основе
нодлиста/поинтлиста, а в соответствии со своим пониманием (к примеру, Ivan
Sidorov похоже на реальное имя, а Night Stranger - не очень).
Хотя понятно, что модератор не может проконтролировать реальность имени, тем не
менее, такой подход играет воспитательную роль. Ведь если человеку необходимо
скрыть свое имя, он может придумать другое, похожее на настоящее, а вовсе
необязательно прикрываться странными псевдонимами (что провоцирует окружающих на
аналогичное поведение).
Другим вариантом может быть персональное (конкретному подписчику) разрешение модератора на использование псевдонима.
Также, иногда практикуется регистрация модератором всех используемых в эхе псевдонимов. При этом список соответствий псевдонимов и реальных имен либо периодически публикуется в эхе, либо хранится у модератора и используется лишь при возникновении конкретных конфликтов.
В последнее время встречается некий компромисс, когда во From: указывается псевдоним, а в клудже @RealName: (который в почтовом редакторе по умолчанию не всегда виден, но при желании доступен) - настоящее имя.
К имени которое указывается в поле From: есть некоторые требования.
Строчка в поле From: не должна содержать кириллицу. Это может вызвать проблемы с программным обеспечением и, кроме того, затрудняет поиск в эхе.
Если человек с данным именем уже есть в FidoNet, принято использовать альтернативные варианты с дополнительным указанием отчества или псевдонима. Например, вместо Ivan Ivanov: Ivan O.Ivanov, Ivan "Night Stranger" Ivanov, Ivan Ivanoff и т.п.
Некоторые подписчики могут умышленно искажать служебную информацию в письме (клуджи PATH, SEEN-BY, поле From и другие) например, с целью выдать свое письмо за чужое #.
Такое поведение - повод для комплейна, который рассматривают сетевой и региональный координаторы. Тем не менее, это не ограничивает модератора в принятии к нарушителю тех мер, которые он считает необходимыми.
Относительно адресов в поле From стоит заметить, что новые узлы должны, до своего появления в мировом нодлисте, использовать в эхах только старые поинтовые адреса. Это связано с тем, что попытки ответить нетмейлом на письма с адресом, отсутствующим в нодлисте, часто бывают неудачны - письма не проходят через некоторые крупные узлы, где проверяется, существует ли отправитель.
Хотя изначально эхи не были предназначены для передачи файлов, на определенном этапе оказалось, что этот метод хотя и неудобен, но позволяет распространить файл более широко, нежели файлэхи (имеющие меньшую распространенность). Кроме того, файлы в эхах удобнее обсуждать. Они как бы связаны с разговором.
Самым популярным (фактически - единственным применяемым) форматом оказался
формат UUE. При помощи программ uuencode/uudecode (и других) файлы
преобразовываются в текстовое представление (7 бит ASCII) и затем обратно, в 8
битовые двоичные файлы.
UUE со временем стали помещать в специальные эхи, у которых в названии
присутствовало .UUE
Во второй половине 1990-х UUE эхи были частично ликвидированы или сняты с регионального бэкбона (из-за большого трафика).
Наиболее радикальные сторонники интенсивного использования UUE пытались изобрести альтернативный формат, который бы не обнаруживался роботами. Однако такие попытки не дали эффекта - формат не прижился и сеть в целом не поддержала этих методов.
Сам UUE еще используется #, поэтому необходимо дать несколько рекомендаций.
Текстовые файлы, фрагменты исходников и другие читаемые тексты не рекомендуется ууенкодить. Это сильно облегчит их чтение и обсуждение.
Для помещения UUE файлов (равно как и больших текстовых файлов) как правило необходимо разрешение модератора. Исключение составляют файлы небольшого объема, что обычно отражено в правилах.
Для UUE файлов:
В поле Subj: крайне желательно указывать номер секции, общее число секций, имя файла, возможно краткое описание в виде #:
[XX/YY] test.zip - исходники игры
Номер секции обязательно должен стоять в начале строки, чтобы подписчики сразу видели все ли секции получены (если номер указывать в конце, он может обрезаться при длинном описании или названии файла).
Каждое письмо должно содержать одну полную секцию, при этом размер одной UUE секции желательно сделать не более чем 10-12kb.
Секции (уже в теле письма) должны начинаться со строки "section XX of YY of file TEST.ZIP" или другой стандартной (это определяется программой-ууенкодером - чаще всего uuencode/uudecode).
Упаковывать файлы рекомендуется распространенными архиваторами, которые есть для всех платформ. Например - ZIP.
Если в эху помещен файл и в ответ получено сообщение "секция NN до меня не
дошла" - это означает, что потеря произошла на одном из промежуточных узлов. С
этим нужно разбираться (обычно тому, кто недополучил секции, с привлечением
отправителя, транзитных узлов), а не просто создавать дополнительную нагрузку,
перепосылая секции.
Проблемы дохождения файлов не должны обсуждаться прямо в эхе.
Если публикуется исполняемый файл, лучше сделать вариант без отладочной информации (увеличивающей его размер) и, по возможности, проверять его на вирусы.
Как правило, в эхах существуют ограничения на объем UUE от одного человека (разово или в течение определенного срока). К примеру, 50 KB в день на человека.
В FidoNet не принято помещать в эхи MIME/BinHex и другие кодированные не UUE файлы.
Намеренная публикация больших (мегабайты) файлов является одним из способов навредить эхе, нарушить функционирование бэкбона, создать проблемы для подписчиков. Реакция на такие действия как со стороны модераторов, так и координаторов обычно оперативная и резкая (вплоть до экскоммуникации).
В большинстве эх русскоязычного FidoNet распространено правило - разрешены
русский (альтернативная кодировка CP866) и английский языки.
В эхах, где обсуждается культура, язык или обычаи других стран, могут
использоваться дополнительные языки.
Принято отвечать на языке, которым было написано оригинальное письмо. Конечно, если этот язык разрешен и вы его знаете.
Если русские слова записывают соответствующими латинскими буквами (латиница, транслит), то чаще всего такой "язык" русским не считается и не приветствуется. В старые времена это было допустимо из-за сложностей с русификацией, однако сейчас трудно найти платформу, с которой можно было бы писать в Fido, но при этом не было возможности использовать русские буквы.
Также не приветствуется замена некоторых русских букв на соответствующие им
английские "для красоты". Подобная замена затрудняет поиск и визуальное
восприятие текста.
Не рекомендуется использовать букву "Ѓ" и "Г" ("йо"), поскольку в разных
русификаторах ее место в кодовой таблице может отличаться. По действующим
правилам русской орфографии 1956 года использование этой буквы факультативно и
требуется только если нужно предупредить неверное чтение или понимание слова.
Письма, набранные большими (прописными) буквами, а также с большим количеством
восклицательных и вопросительных знаков воспринимаются как крик и,
соответственно, допустимы лишь в исключительных случаях.
Недопустимо использовать большие и маленькие буквы вперемешку для "украшения".
Русская буква "Н" (0x8d) должна заменяться (русификатором или почтовым редактором) на соответствующую английскую "H" (0x48). Эта проблема идет от программного обеспечения для FTN сетей, которое русскую "Н" (символ Soft CR) пропускает. И по сей день проблема актуальна, хотя уже не так, как раньше. Также встречается (хотя теперь неактуальна) предупредительная замена русских букв "р" и "у" на аналогичные английские.
Для международных эх (имеется в виду дальнее зарубежье) обычно вводятся дополнительные ограничения - запрещаются символы с кодом >127 ASCII (т.е. разрешается только латиница, цифры, знаки препинания).
Отдельно стоит упомянуть о проблеме грамотности. Хотя на мелкие опечатки и запятые обычно никто не обращает внимания, но постоянное повторение одной и той же ошибки (например "извЕни" вместо "извини") вызывает естественное раздражение. Если ошибок слишком много, трудно расценить такое письмо как русскоязычное.
Важно, однако, пресекать попытки участников обсуждения поправлять ошибки прямо в эхе #. Такая "помощь" - характерный способ оскорбить или завязать флейм. Если человек искренне хочет указать другому на ошибку - он пишет ему нетмейл. Публичные исправления ошибок - скорее способ унизить, а не помочь. Грамотность, так же как вежливость или умение правильно держать вилку, далеко не всегда характеризует человека.
Существует технический способ автоматически пропускать (стирать) в почтовом редакторе письма от определенных авторов, с определенным subject'ом, либо по другим условиям. Такое действие называется "поставить твит" на человека, тему и т.д. Например, в GoldEd для этого используются соответственно TwitName и TwitSubj в golded.cfg
Это может быть полезно в случаях если:
- Какой-либо человек или обсуждаемая тема раздражает и невозможно спокойно игнорировать письма;
- Время ограничено и поэтому трудно читать эху с большим трафиком. При этом оставляют наиболее интересных собеседников или исключают наименее интересных;
Конечно, чаще всего твиты применяются против раздражающих людей. Некоторые даже обмениваются списками (твитлистами), пытаясь сэкономить время на выяснении того, кто достоин твита, а кто нет.
Надо заметить, что использование твитов - крайняя мера в том смысле, что она лишает возможности объективно оценивать ход дискуссии и вообще содержимое эхи. Предпочтительнее просто игнорировать письма, если позволяет состояние нервной системы.
Для модераторов эх использование твитов в принципе недопустимо.
Во некоторых эхах, помимо правил, регулярно публикуются FAQ (Frequently Asked Questions) - ответы на часто задаваемые в эхе вопросы #. FAQ ведет (ко)модератор, кто-либо по его просьбе, либо любой подписчик, независимо от модератора (хотя регулярную публикацию FAQ безусловно нужно согласовать с модератором).
Основное назначение FAQ - сделать беседу в эхе более содержательной за счет снижения числа одинаковых, часто задаваемых, очевидных вопросов. И, конечно, хороший FAQ можно рассматривать просто как источник проверенной, качественной информации по тематике эхи.
Иногда модератор может даже наказывать подписчиков за вопросы, ответы на которые уже содержатся в регулярно публикуемом FAQ.
FAQ чаще всего организуют следующим образом:
оглавление (список заголовков вопросов, с разбивкой по темам)
вопрос_1
ответ_1
...
вопрос_n
ответ_n
Наиболее простой способ составления FAQ - просмотр эхи за большой период времени
и отбор наиболее информативных фрагментов писем. На один вопрос вполне может
быть несколько ответов, даже совсем разных (в будущем подписчики сами уточнят
вам что правильно, а что нет).
Полезно, хотя и необязательно, указывать, кем был написан тот или иной фрагмент
текста. При большом числе фрагментов это становится излишним, и тогда можно
просто ввести отдельный раздел "Благодарности".
Спрашивать в каждом случае разрешения на включение части письма в FAQ не нужно -
такое разрешение подразумевается самим фактов написания писем в эху.
То, насколько часто следует публиковать FAQ, зависит от его объема, от трафика в эхе. В любом случае, не чаще чем правила.
Дополнительно можно размещать FAQ на FAQ-сервере (робот, который по запросу нетмейлом отсылает нужную часть FAQ) #. Также полезно размещать FAQ (вместе с правилами эхи и вспомогательной информацией) на сайте в Интернет, а в правилах и в origin'е (ко)модератора давать ссылку на этот сайт.
Ссылаясь на ресурсы в Интернет нужно всегда помнить, что многим (особенно, за пределами Москвы и Санкт-Петербурга) он недоступен или доступен в очень ограниченном виде.
Помимо FAQ в некоторых эхах может регулярно публиковаться другая полезная информация. Например, в студенческих - списки студентов различных вузов, имеющих адреса в FidoNet. В сисопских - правила выдачи узлов, текущая статистика, различные списки и т.п.
В эхах с большим трафиком # модераторы и подписчики иногда принимают специальные меры, чтобы облегчить чтение и поиск.
Например, модератор может требовать от подписчиков, чтобы Subj письма отражал
содержимое. К примеру, в эхе, где обсуждают разные сотовые телефоны или
карманные компьютеры, в Subj необходимо указывать стандарт связи (GSM, NMT,
CDMA) и операционную систему под которой работает компьютер соответственно. В
RU.PALMTOP необходимо было указывать в Subj тип PDA, о котором идет речь ([palm],
[psion], [pocketpc] и т.п.). В RU.DELPHI - версию Delphi (D1,D2,D3,Dx) и область
применения программы (DB,SQ,VCL,GFX,OLE,APE, и т.д.), в
SU.RENDER - название пакета (MAYA, LW) и
темы (TECH, ART, INFO, MISC)
#,
в RU.PHOTO.DIGITAL темы (Scan,
Camera, Acc, DSLR, P&S, Print, Edit, Misc)
#
Надо заметить, что поскольку это требование для новых подписчиков неочевидно, в
эхах, где часто появляются новички, будет трудно обеспечить его выполнение -
далеко не все новые подписчики читают правила прежде, чем писать в эху.
В FidoNet один и тот же Subj часто не меняется многие месяцы (даже когда под ним
обсуждаются уже другие вопросы), и бороться с этим практически невозможно. Чаще
всего такое явление можно наблюдать в эхах общей тематики (жизнь, политика).
Другой способ - перечисление в тексте письма (или в клудже @KEYWORDS) ключевых
слов для поиска.
Такой способ редко приветствуется модераторами, поскольку увеличивает размер
письма, снижает удобство чтения.
Отношение модераторов и подписчиков к гейтованию эх из FidoNet в другие сети и из других сетей в FidoNet всегда было неоднозначным и острым вопросом #. Кратко об этом уже сказано в разделе "История".
Под термином "гейтование" чаще всего понимается обмен письмами между эхами
FidoNet и ньюсгруппами (форумами, сайтами) в сети Интернет. При этом письма со
стороны Интернет имеют в качестве адреса во "From:" FidoNet адрес узла-гейта.
Реже встречается гейтование из других FTN сетей. В этом случае во "From:" можно
видеть либо адрес узла-гейта, либо не FidoNet (хотя и FTN) адрес. Последнее
является грубым техническим нарушением, поскольку ответить на такое письмо
нетмейлом нельзя.
В настоящее время (2003 год) ситуация с гейтованием эх выглядит следующим образом.
Гейтование на R/O (возможность читать фидошные эхи из Интернет) вызывает возражение только у очень немногих модераторов эх, обычно это связано с желанием ограничить область распространения (некоторые местные эхи, локалки и т.д.).
Полное гейтование (возможность не только читать, но и писать из Интернет в фидошные эхи #) - по-прежнему вызывает споры и конфликты. Далее под "гейтованием" будет пониматься именно полное гейтование.
Существует несколько гейтов, из которых наибольшую часть внешнего FidoNet трафика создает крупный узел 5020/400 (иерархия FIDO7.*). От пользователя Интернет на этом гейте требуется регистрация #, однако все зарегистрированные пользователи автоматически получают R/W доступ (на чтение и письмо) ко всем эхам на узле. Другими словами, по умолчанию в эхе, которая находится на таком узле, гейтование оказывается разрешенным - гейтмастер не изучает правила на предмет запрета гейтования. Для оправдания такого поведения гейтмастерами приводится аналогия между гейтом и BBS. Однако такая формальная аналогия не учитывает, что раньше BBS, совмещенные с FidoNet станциями, имели очень небольшое число пользователей, поведение которых могло легко контролироваться единственным сисопом. Другое отличие - в критериях, по которым пользователи получали доступ к BBS и к гейту.
Впрочем, модератор может нетмейлом потребовать от гейтмастера отключения конкретного пользователя гейта или полного запрета гейтования для его эхи (при этом, для гейта на 5020/400, пользователь будет отключен от Fido эх полностью, а не только по данной эхе). Также модератор может наоборот - пожелать гейтования своей эхи, написав нетмейл гейтмастеру.
Поскольку обычно гейтом является крупный раздающий узел или хаб, при возникновении конфликтов *C вынуждены учитывать, что санкции к такому узлу повлекут недовольство как минимум у его многочисленных линков со стороны FidoNet и пользователей со стороны Интернет (включая модераторов, которые работают через Интернет). Такой узел оказывается "священной коровой" и при конфликтах имеет серьезное неформальное преимущество перед обычным узлом.
В общем и целом встречаются следующие возражения против гейтования:
- Низкий культурный уровень значительной части писем со стороны Интернет. Обычно это выражается в неумении корректно спорить, нежелании добровольно подчиняться модераторам, большом самомнении и самоуверенности;
- Различные принципы общения, связанные с техническими и организационными особенностями FidoNet и Интернет;
Например:
- В Интернет-форумах распространена практика переписки в поле "Subject" писем (без заполнения тела письма) - т.е. обмен короткими репликами. В FidoNet такая практика отсутствует, а за короткие реплики ("согласен", "я тоже") часто даже наказывают;
- В Интернет скорость обмена письмами технически может быть по сравнению с
FidoNet очень высока. Наряду с очевидными плюсами это имеет и отрицательную
сторону: В FidoNet письма обычно уходят лишь раз в час или сутки и, поскольку
автор осознает, что быстрого ответа не будет, он больше внимания уделяет смыслу
письма, обдумыванию ответов и вопросов.
Кроме того, появляется возможность поправить текст, если через некоторое время
он показался автору неполным или чрезмерно эмоциональным.
Это различие будет стираться по мере увеличения числа IP узлов в FidoNet и
использования FTN over IP;
- Различные традиции оформления писем. В Интернет распространена практика, когда при ответе на письмо оно полностью цитируется, причем в конце письма. В FidoNet это называется "излишнее цитирование" и вызывает раздражение подписчиков, не говоря о нарушении правил;
- В Интернет письма читают (и, соответственно, отвечают) не подряд, а по темам. В FidoNet чаще всего подряд.
- В Интернет распространено обращение на "Вы", в FidoNet это воспринимается как высокомерное отношение;
- В Интернет принято (и это связано с техническими особенностями) писать письма в эху/ньюсгруппу, обращаясь всегда к All (поле X-Comment-To не заполняется). В эхах FidoNet это вызывает недоумение и затрудняет общение, т.к. здесь, как правило, обращаются к конкретному собеседнику (за исключением случаев, когда вопрос или информация по своей сути обращена ко всем). Постепенно пишущие из Интернет начинают использовать указанное поле. Гейты, как правило, его поддерживают;
- Невозможность требовать от узла-гейта ответственности за исходящий трафик,
равнозначной обычному узлу сети FidoNet.
С одного FidoNet адреса гейта фактически могут писать сотни людей и засчитывать
все их нарушения узлу-гейту, как если бы это был обычный узел, бессмысленно -
это быстро приведет к его отключению (т.е. равносильно запрету гейтования);
- Невозможность принимать сколько-нибудь эффективные меры по отношению к нарушителям из Интернет, что связано с легкостью смены адреса, отсутствием в Интернет понятия членства, взаимной ответственности, исключения из сети и т.д.;
Из перечисленных возражений против гейтования, последние два представляются
наиболее важными. Оба связаны с принципиальным отличием FidoNet от Интернет,
которое, по мнению автора, заключается в том, что FidoNet - в первую очередь
сообщество, в то время как Интернет - транспорт.
Разумеется, внутри Интернет также существуют сообщества, каковым являются, к
примеру, отдельные форумы или чаты. Однако они или невелики по размерам, или
носят неустойчивый характер - зависят от личности хозяина сервера, от
финансирования, от доброй воли тех или иных организаций.
Что понимается здесь под сообществом? Предполагается:
- Членство в сети под определенным адресом (существует процедура принятия в сеть
и исключения из нее). Быстро сменить адрес довольно сложно, причем с каждой
новой попыткой это будет все сложнее;
- Добровольное принятие на себя обязательств: при приеме в сеть - следование
Policy, при подписке на эху - соблюдение ее правил;
- Единая структура, позволяющая принимать и выполнять обязательные для всех
решения (*C, *EC, модераторы);
- Ответственность, в том числе взаимная, за свои действия - в случае
некорректного поведения узел может выгнать своего поинта, аплинк понимает, что
некорректно ведущий себя даунлинк - источник проблем для него, *C может
экскоммуницировать узел, узлы могут не переизбрать NC/RC или лишить его поста,
модератор может отключить произвольный узел или группу узлов от своей эхи,
подписчики могут уйти из эхи в другую или новую при неадекватном модерировании;
В случае с Интернет перечисленные черты фактически отсутствуют:
- Членства в сети нет, любой человек в течение пары минут может получить
несколько адресов, не предоставляя о себе никаких данных кому-либо;
- Как правило, отсутствуют какие-либо обязательства при работе в сети;
- Отсутствует единая структура принятия и выполнения решений - какие-либо
действия предпринимаются отдельными провайдерами независимо друг от друга или
иногда по согласованию, либо по требованию властей, обычно плохо знакомых с
сетями;
- Работающий в сети в общем случае не несет реальной ответственности за свои
действия по рассылке спама, некорректному поведению. В любой момент он может
оперативно сменить провайдера, сменить адрес, писать от чужого или выдуманного
имени;
- Взаимная ответственность существует, например, в виде отключения клиента
провайдером, блокирования почты от провайдера, который не отключает спамера и
т.п. Однако поскольку единой структуры не существуют, эти действия не являются
ни для кого обязательными и не слишком эффективны;
Подводя итог, можно сказать, что в Интернет нет механизма, который позволял бы
эффективно и на длительное время пресекать чьи-либо некорректные действия.
Причем отсутствие такого механизма обусловлено самими принципами организации и
развития сети.
Поскольку в FidoNet такой механизм есть, гейтование часто воспринимается как
явление, его разрушающее или ослабляющее (и как следствие - снижающее
конструктивность и комфортность общения).
Наилучший выход - способствовать развитию FTN over IP, улучшать программное обеспечение для такого доступа. Роль полного гейтования в развитии FidoNet должна быть снижена, достаточно использовать R/O гейтование, чтобы показать потенциальным пользователям содержимое эх.
Основной и практически единственной причиной, по которой может потребоваться разделение эхи на несколько, является рост трафика # - в эхе начинают смешиваться разные темы, важные сообщения теряются среди прочих и т.д.
Разделение может происходить по двум признакам:
- По тематике;
- По степени важности публикуемых писем;
Пример первого варианта - известное разделение эхи SU.HARD&SOFT на SU.HARDW и SU.SOFTW, а затем разделение SU.HARDW на множество эх SU.HARDW.*
Второй вариант можно проиллюстрировать на примерах:
SPB.SYSOP -> SPB.SYSOP + SPB.SYSOP.INFO
(и позднее появившихся SPB.SYSOP.TALK , SPB.SYSOP.IMHO, SPB.SYSOP.FILTERED)
R50.SYSOP -> R50.SYSOP + R50.SYSOP.TALK
(и позднее появившихся R50.SYSOP.CLUB, R50.SYSOP.DRUNK, R50.SYSOP.INFO)
Рассмотрим одно интересное отличие - так называемый (условно) "питерский" и "московский" подход к разделению сисопской эхи. На определенном этапе с эхами R50.SYSOP и SPB.SYSOP возникла проблема - слишком большой трафик, в котором трудно было находить важные для функционирования сети сообщения. Стало ясно, что должна появиться эха, где будут публиковаться только важные сообщения, чтобы сисопы, у которых нет времени на чтение всего трафика, были в курсе основных событий.
Эта задача решалась по-разному:
Дополнительно к R50.SYSOP была создана R50.SYSOP.TALK , причем в .TALK были вынесены совсем общие разговоры, а в R50.SYSOP введены ограничения ("московский" подход).
Дополнительно к SPB.SYSOP была создана SPB.SYSOP.INFO, причем сам SPB.SYSOP остался для общих разговоров, а в SPB.SYSOP.INFO были введены ограничения ("питерский" подход).
Представляется, что второй подход имеет то преимущество, что он не требует
специальных действий по подавлению разговоров, смене тематики в исходной эхе
(SPB.SYSOP) - просто создается новая (SPB.SYSOP.INFO).
С другой стороны ясно, что в случае с первым вариантом тем, кого интересует лишь
важная информация, нет необходимости специально подписываться на новую эху - они
получают все ту же старую, но "очищенную" (R50.SYSOP).
Позднее описанное здесь состояние эх частично изменилось, однако вопрос о способе разделения возникал и в других случаях.
Похожая ситуация была с SPB.FILES, дополнительно к которой появилась SPB.FILES.NEW
В SPB.FILES.NEW стали публиковаться анонсы о новых файлах доступных для FREQ, а
в SPB.FILES запросы (ранее и то и другое происходило в одной SPB.FILES)
Позднее появились также
SPB.FILES.TALK, SPB.FILES.ALLFIX, SPB.FILES.MP3.ROCK, SPB.FILES.VIDEO.
Более нейтральной ситуаций является добавление к уже существующей эхе вспомогательных.
Например, DEMO.DESIGN -> DEMO.DESIGN + DEMO.DESIGN.UUE + DEMO.DESIGN.WANTED
В этом случае .UUE эха служила для публикации UUE файлов (небольшие intro, исходники и т.п.) по тематике DEMO.DESIGN, а .WANTED - для поиска файлов.
Стоит добавить, что при разделении эхи желательно создавать новые дополнительно к существующей, а не вместо нее. Это связано с трудностью ликвидации эх.
Ликвидация эхи в FidoNet - задача довольно сложная, причем тем более сложная, чем более распространена эха.
Простое сообщение вроде "эта эха более не существует, просьба от нее отписаться" даст лишь частичный эффект.
Поскольку на крупных узлах обычно включен режим автоматического создания новых эх, "прибитая" эха будет создаваться вновь и вновь, так как нельзя заставить людей полностью прекратить туда писать (вновь подписавшиеся уж точно не будут знать, что она прибита).
В качестве примера можно вспомнить эху SU.HARDW, которая была разделена на несколько SU.HARDW.*, а сама ликвидирована. Тем не менее, в течение примерно пяти лет она то и дело появлялась на разных узлах.
В связи с этим, если есть возможность, эху лучше оставить и перепрофилировать. В случае с SU.HARDW возможно имело смысл использовать ее для обсуждения "железа", не подходящего под другие SU.HARDW.* (то есть вместо существующей теперь SU.HARDW.OTHER). Впрочем, это спорное решение.
Так или иначе, если есть твердое намерение эху ликвидировать, то необходимо:
Сообщить в эхе (а также в параллельных эхах той же иерархии, если такие есть) о факте ликвидации и попросить подписчиков отписаться и удалить эху у себя.
Сообщить о факте ликвидации *EC.
Написать хабам письма с просьбой эху прибить и настроить эхопроцессоры так, чтобы она не могла автоматически создаваться. На некоторых бэкбонах поддерживается специальный ф