#371
|
|||
|
|||
Отображение иллюстраций из ююков и фэх в векторном гипертекстовом
Alexandr Solov\'yev написал(а) к Alexey Vissarionov в Oct 16 10:21:30 по местному времени:
Да не заглючит твой компьютер во веки веков, о Alexey! 09 Окт 16 02:38, ты писал(а) мне: ASy>>>>>>>> счас полетит клип "лебедь белая". Весом мегабайт в 300. AV>>>>>>> Ну и свалится этот ююк в badmail на ближайшем хабе ASy>>>>>> Это если не порежут этот ююк на мелкие кусочки. AV>>>>> Отстрелить многосекционный ююк еще проще. ASy>>>> А что инициирует его отвал в беды? Если размер - то порезать я ASy>>>> могу хоть по 64 кило. :-) AV>>> Сам факт многосекционности. ASy>> ХПТ такого, вроде, не умеет. AV> Это ты его настраивать не умеешь :-) Это у тебя туда перловки насовано. Я же пользую натурпродукт. Без усилителей вкуса и ГМО. :-) ASy>> Но можно и чем другим словить. Хоть трекером. AV> Если уметь настраивать hpt - никакой трекер не нужен. Да я уже обкурился мануалами - не умеет он анализировать потроха мессаг. ASy>>>> Главное чтобы в раздачу это не ушло. AV>>> Без явного разрешения сисопа грамотно настроенного хаба - AV>>> не уйдет. А отправитель получит матерное письмо в полном AV>>> соответствии 2.1.7 FPD. ASy>> Если ловушка стоИт до тоссера. AV> Оно в самом тоссере. Покажи! ASy>> Но как тогда понять, что этот многосекционник размером со своп ASy>> винды, а не какой смешной поинт небольшой файл порезал на мелкие ASy>> куски? Особенно если вливают аккуратно, а не все махом. AV> А зачем? Ну а зачем залили "лебедьбелую" в какащенку? В целях нагадить ессно. AV> Многосекционный постинг - в badmail, если сисоп в течение суток не AV> сказал пропустить - в /dev/null По полиси развернуть полагается... AV>>>>> А если этот кто-то еще и не умеет откладывать такие сообщения AV>>>>> в сторону для последующего ручного разбора - этому кому-то о AV>>>>> том, чтобы стать хабом, даже думать не следует. ASy>>>> А нужен этот гемор? Эхи - не транспорт для файлов. (с) не ASy>>>> помню. AV>>> Нужен. Как минимум для соблюдения упомянутого выше 2.1.7 FPD. AV>>> Иначе нехрен лезть в хабы. ASy>> А не проще закрыть ююки вовсе? Как класс. AV> А зачем? Иногда, наоборот, бывает даже полезно хранить бинарные данные AV> как неотъемлемую часть сообщения - просто злоупотреблять этой AV> возможностью не следует (а это уже забота модераторов). Может сработать принцип веера. Раз в одном месте можно люлючить, то можно везде. И если в однои месте модератор за этим следит, то в другом модератор клал на это или его в живых давно нету. А реакция наших хабов предсказуема - они разбираться не будут кто виноват. Долбанут что под руку попало. Всего наилучшего в этом лучшем из миров! Alexandr Solov'yev ... Не дадим занести Зеленого Змия в Красную книгу!!! --- Oldest fimooznik 1.1.5-b20160322 |
#372
|
|||
|
|||
Отображение иллюстраций из ююков и фэх в векторном гипертекстовом
Alexey Vissarionov написал(а) к Alexandr Solov\'yev в Oct 16 11:22:22 по местному времени:
Доброго времени суток, Alexandr! 09 Oct 2016 09:50:02, ты -> мне: AV>>>>>> Отстрелить многосекционный ююк еще проще. ASy>>>>> А что инициирует его отвал в беды? Если размер - то порезать я ASy>>>>> могу хоть по 64 кило. :-) AV>>>> Сам факт многосекционности. ASy>>> ХПТ такого, вроде, не умеет. AV>> Это ты его настраивать не умеешь :-) ASy> Это у тебя туда перловки насовано. ~/fido/lib/hptfunctions.pl - это конфигурационный файл. ASy> Я же пользую натурпродукт. Без усилителей вкуса и ГМО. :-) Ага, вижу: ASy> @TID: hpt/w32-mvcdll 1.4.0-sta 19-03-04 Как там эта протухшая рыба по чухонскому рецепту называется... А! Лютефиск :-) ASy>>> Но можно и чем другим словить. Хоть трекером. AV>> Если уметь настраивать hpt - никакой трекер не нужен. ASy> Да я уже обкурился мануалами - не умеет он анализировать ASy> потроха мессаг. Умеет. ASy>>> Если ловушка стоИт до тоссера. AV>> Оно в самом тоссере. ASy> Покажи! do { use bytes; $rc = length($text) }; if ($rc > 16777216) { return "Message too large - must be approved manually"; } AV>> Многосекционный постинг - в badmail, если сисоп в течение AV>> суток не сказал пропустить - в /dev/null ASy> По полиси развернуть полагается... Не развернуть, а уведомить отправителя. ASy>>> А не проще закрыть ююки вовсе? Как класс. AV>> А зачем? Иногда, наоборот, бывает даже полезно хранить бинарные AV>> данные как неотъемлемую часть сообщения - просто злоупотреблять AV>> этой возможностью не следует (а это уже забота модераторов). ASy> Может сработать принцип веера. Раз в одном месте можно люлючить, ASy> то можно везде. Я правильно понимаю, что слово "можно" ты используешь в значении "есть техническая возможность"? Дык она есть всегда... ASy> И если в однои месте модератор за этим следит, то в другом ASy> модератор клал на это Это его право. ASy> А реакция наших хабов предсказуема - они разбираться не будут ASy> кто виноват. Долбанут что под руку попало. Это, соответственно, их право. -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Политкорректная замена термина "черная дыра" - "афроотверстие" --- /bin/vi |
#373
|
|||
|
|||
Отображение иллюстраций из ююков и фэх в векторном гипертекстовом
Mithgol the Webmaster написал(а) к Alexandr Solov\'yev в Oct 16 14:47:18 по местному времени:
Так было 10:57 07 Oct 16 написано от Alexandr Solov'yev к Mithgol the Webmaster: ASy> Экскоммуницировали сисопа хаба. С регионального уровня. За то, что его ASy> поинт обидел SKL. Причем перекрыть сам фонтан люлюков не очень-то ASy> и стремились. Тут важна была демонстрация силы. Факт тот, что куча ASy> поинтов и линков остались без СМ аплинка. Не только автор пресловутого ASy> люлюка. Был создан прецедент, позволяющий теперь удалить любой узел за ASy> любую погрешность в работе без попыток разобраться. MtW>> Кроме того, вроде как вспоминаю, что белая лебедь прошла в то время, MtW>> когда ещё дискеты были в употреблении. С тех пор и хранилища MtW>> информации стали куда пожирнее, и каналы связи стали куда пожирнее, MtW>> так что аналогичный вред стало несколько труднее нанести, в MtW>> особенности простым спамом, так что можно же ещё надеяться, что теперь MtW>> пострадают виновные спамеры и более никто. ASy> Если "лебедьбелая.мп3" весила 3-4 мегабайта (вроде бы, уже не помню), то ASy> счас полетит клип "лебедь белая". Весом мегабайт в 300. Технология ASy> позволит. Благодаря твоим разъяснениям становится вполне ясно, что причина того инцидента такова, что устранение спама (то есть коммерческой рекламы) или устранение UUE (то есть технологии преобразования файлов в текстоподобные данные и обратно) никак не способна с этой причиною покончить. С немалым сожалением вижу, что вопрос жидокащенизма (и, шире, еврейский вопрос в целом) подменяется вопросом о 'люлюках'; это, вне всякого сомнения, форма невротического замещения, или пост-травматического триггера, или чего-то ещё в этом же роде внерассудочного, позволяющего проигнорировать внетехнологический расовый смысл того инцидента и прецедента. Прошу в дальнейшем использовать какие-нибудь другие аргументы против UUE, этот аргумент не годится. MtW>> Во-первых, если я правильно понимаю, фрек (файловый запрос) никак MtW>> не возможно отправить аплинку и получить от аплинка отклик без того, MtW>> чтобы заодно не взять у него всю новую почту (и, может быть, также MtW>> свою ему выслать), а это дольше, чем запрос к FTP. ASy> 1. При современных скоростях это "дольше" сколько займет секунд? Мне кажется, что здесь ранее оглашались аргументы о том, что не все сисопы и тем более не все пойнты работают на современных скоростях, что кое у кого фиговый 3G. ASy> 2. Фрекать необязательно именно с аплинка. Пожалуй, этот аргумент справедлив. Хотя он проблематичен в смысле той проблемы, которая называется tragedy of the commons (трагедия общественных земель): если с какого-то узла будет фрекать слишком много посторонних фидошников, которые никто для него (даже не даунлинки), то узел может быть вовлечён в чрезмерные издержки и в итоге закроет фрек нафиг (или ограничит даунлинками, способными предъявить пароль). MtW>> Формирование файлового запроса (фрека) ── простое дело, так что его MtW>> в Голдеде можно видеть реализованным; ASy> Именно так. Все уже готово. Пользователи голдедов смогут получить ASy> контент. А если они его смотрят через жжжж, то это их выбор редактора. ASy> :-) MtW>> но речь же идёт вдобавок об отображении отклика, так что надо учить MtW>> просмотрщик дожидаться ответа мейлера; а найдутся ли программисты, MtW>> на это непростое дело готовые решиться? ASy> Просмотровщику ничего не нужно ждать. Он должен знать, где лежит файл. ASy> Сфреканый или полученный по фэхе - ему все равно. Возможно, я недостаточно ясно выразился, но речь шла о том просмотрщике, какой показывает пользователю сообщение фидопочты. Если в сообщении есть картинка и если адрес картинки предполагает фрекание, то получается, что просмотрщик должен сформировать файловый запрос (фрек), запустить мейлер и дожидаться того, пока мейлер соединится и получит запрошенный файл. Не правда ли? Конечно, фреканием теоретически может заранее заняться эхопроцессор (тоссер) или препроцессор (то есть запускаемый изнутри эхопроцессора софт, который имеет дело с распакованными пакетами фидопочты). MtW>> Сам же я НTick не употребляю и фэх не имею, так что на опыте не мог MtW>> испытать правоту или неправоту вышеизложенного впечатления. ASy> Вот теперь я понял, откуда такая антипатия к фэхам. Предполагаю, что я не единственный из числа сисопов, фэх не имеющих. Можем для подтверждения этого обстоятельства попробовать устроить перепись. Впрочем, ты можешь на это ответить, что можно и не иметь фэх, однако фрекнуть файл, по фэхе прошедший. MtW>>>> Простая пользовательская машина может любым современным MtW>>>> браузером Интернета открывать SVG. (В роли браузера может MtW>>>> выступать Mozilla Firefox, Google Chrome, Opera и др.) ASy>>> Значит, без постоянного доступа в инет и стороннего ПО читать ASy>>> такие сообщения невозможно? MtW>> Доступа в Интернет не нужно. Браузер может открыть файл с диска с той MtW>> же (или даже большей) лёгкостью, что и из Интернета. ASy> А где на диске все это есть? Вот в фэхе все уже есть. Оттуда открывать - ASy> милое дело. И опять браузер. Без него никак? Те же самые вопросы относятся буквально к любому заююченному файлу. Где лежит на диске заююченный файл? Может ли GoldED+ обойтись без внешних средств для его просмотра? (Просто так получилось, что заююченные SVG можно открыть браузером.) ASy>>> Тогда они влет попадут под 2.1.4. Уже без поправок, что голдед ASy>>> тоже понимает UUE и подобного. Один особо умный начнет травлю, ASy>>> другой его поддержит. А особо умных в фидо всегда хватало. :-) ASy>>> Не во всем, но нужно делать на них поправку. MtW>> Сложно веровать. Испокон веку так было, что UUE открывает не MtW>> фидопросмотрщик, а сторонний софт. ASy> Но даже голда умеет кодировку UUE превратить в читаемый обычным набором ASy> софта файл. Который откроется без доступа в инет и прочих плясок с ASy> бубнами. Тогда при чём тут 2.1.4 вообще? ASy>>>>> Значит надо ставить очередную приблуду? MtW>>>> Я надеюсь, ты не ожидал того, что существующая приблуда MtW>>>> (GoldED+) неожиданным и волшебным образом начнёт в своём MtW>>>> алфавитно-цифровом окошке отображать также и растровую да MtW>>>> векторную графику? ASy> Нет. Но отобразит текст. Читаемый. А не крокозяберы. Дык что ж поделать, когда это не текст, а картинка. MtW>> Даю пояснение: PhiDo ── сторонний просмотрщик гипертекстовой MtW>> фидопочты, и он открывает не один только векторный рисунок, но и всё MtW>> окружающее его сообщение фидопочты. ASy> Хорошо, есть эхи, поддерживающие данную технологию? Я хочу посмотреть, ASy> как это выглядит. Посмотри Ru.Anime в PhiDo. Правда, в силу специфики там иллюстрации будут не векторные, а растровые, и не заююченные, а внешние (в Интернете лежащие), а так всё то же самое: PhiDo покажет сообщение, а в сообщении картинку или несколько картинок. MtW>> Если же мы говорим не о флоппинете в узком смысле, а вообще об MtW>> оффлайновом чтении Фидонета, то и тут, опять же, опасаться нечего. ASy> Я и говорю об оффлайновом чтении. Ты же или тянешь фидо в инет - ASy> или предлагаешь гонять ююки только потому, что у тебя нет фэх и ты ASy> не хочешь разобраться с ними и настроить фэхопроц. Там, кстати, все ASy> просто как швабра. Тогда простой вопрос. У тебя также конфигурация включает в себя условные выражения в зависимости от переменной [module], как в изложенном ниже примере? include /fido/etc/husky/common.cfg include /fido/etc/husky/packer.cfg include /fido/etc/husky/paths.cfg include /fido/etc/husky/fpaths.cfg if [module] == hpt include /fido/etc/husky/general.cfg elseif [module] == htick include /fido/etc/husky/fgeneral.cfg else include /fido/etc/husky/nlgeneral.cfg endif include /fido/etc/husky/links.cfg if [module] == hpt include /fido/etc/husky/files.cfg include /fido/etc/husky/route.cfg elseif [module] == htick include /fido/etc/husky/ffiles.cfg endif include /fido/etc/husky/StdAreas.cfg CommentChar ; if [module] == hpt include /fido/etc/husky/areas.cfg include /fido/etc/husky/ccopies.cfg elseif [module] == htick include /fido/etc/husky/fareas.cfg include /fido/etc/husky/announce.cfg endif MtW>> Во-первых, браузер может открыть файл с диска с той же (или даже MtW>> большей) лёгкостью, что и из Интернета. ASy> А откуда он возьмет мультимедийный контент? Из UUE декодирует же. Если это картинки. Если ты имеешь в виду более тяжёлый мультимедийный контент (видео, например), то скажи об этом ── обсудим. MtW>> Во-вторых, фэхи равны UUE в оффлайновости (если на узле есть фэхи) и MtW>> даже чуть уступают (если на узле нет фэх, так что файлы надо фрекать MtW>> по межузловому соединению или скачивать с интернетовского FTP). ASy> Ну тут уже выбор аплинка. Счас с этим нет проблем. Что ты имеешь в виду? (С чем именно нет проблем?) MtW>>>> Вообразим себе постпроцессор, который обозревает все пакеты MtW>>>> фидопочты после распаковывания их эхопроцессором, находит в MtW>>>> этих пакетах фидонетовские руны (Markdown-подобную разметку) MtW>>>> иллюстраций и тотчас же запрашивает иллюстрации из MtW>>>> P2P-распределённой файловой системы IPFS. Тогда, даже и сидючи MtW>>>> без Интернета, иллюстрации ты эти мог бы лицезреть невозбранно, MtW>>>> так как у тебя в IPFS они уж были б. ASy> А для меня дурака можно подробнее? Контент не вырастает просто так сам. ASy> В любой файловой системе... Есть такая штука ── P2P-распределённая файловая система IPFS. Установив себе её поддержку, можно в дальнейшем складывать в неё файлы (они тогда копируются в базу данных, хранимую на диске) и брать из неё файлы (они тогда берутся из базы данных на диске, а если там отсутствуют, то берутся по Интернету у других людей, также установивших IPFS и имеющих у себя этот файл). Вообразим себе постпроцессор, который обозревает все пакеты фидопочты сразу после распаковывания их эхопроцессором (а тогда-то Интернет ещё есть!), находит в этих пакетах фидонетовские руны (Markdown-подобную разметку) иллюстраций и тотчас же запрашивает иллюстрации из P2P-распределённой файловой системы IPFS. Тогда иллюстрации эти невозбранно из Интернета попадают на диск в базу данных IPFS. Тогда в дальнейшем, даже и сидючи без Интернета, иллюстрации ты эти мог бы лицезреть невозбранно, так как у тебя в IPFS они к тому времени были бы. ASy>>> Неужели сложно будет научить редактор кешировать скачаное ASy>>> из инета? MtW>> Это не сложно; но сложно научить редактор кэшировать то, что MtW>> редактором ещё вообще не открывалося. ASy> И не надо. Человеку это неинтересно - зачем ему тратить трафик и ресурсы? А затем, чтобы в дальнейшем, даже и сидючи без Интернета, иллюстрации (заранее скачанные) лицезреть невозбранно, так как в кэше они к тому времени были бы. MtW>> Обрабатывать принятую (но ещё не открытую редактором) фидопочту MtW>> способен только эхопроцессор (тоссер) или запущенный им обработчик MtW>> (постпроцессор). Другого пути к этому идеалу быть не может. ASy> Минимизировать трафик и дисковое пространство - это в том числе то, ASy> на чем счас еще может выехать фидо. Иначе собачка умрет. Я не согласен с этим утверждением. Считаю справедливым утверждение отчасти противоположное: для выживания Сеть Фидонет должна перестать быть текстовою, в её сообщениях должна появиться возможность либо непосредственной (в UUE), либо опосредованной (в UUE в другой эхе, в файле в фэхе, в файле в IPFS, в файле по фреку, в UUE нетмейлом по роутингу) появления нетекстовых данных различного формата: векторных иллюстраций, растровых иллюстраций, звукозаписей, видеозаписей. В противном случае Сеть Фидонет окончательно проиграет идущее уж состязание её с новейшими социальными сетями, которое Фидонет может и выиграть благодаря очевидным своим достоинствам, из которых первым является отсутствие рекламы, а вторым является отсутствие гиперцентрализации расходов и связанных с этим ограничений (вызванных тем, что пока ещё центральный сервер может у себя хранить меньше, чем каждый из большинства конечных пользователей, что доказано удобствами от перехода к файлообмену, наблюдаемыми распространителями видео). Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj] ... почему казахи Омск "коверкают", а ты им позволяешь? (Волков в Ru.Spelling) --- Знаешь ли ты, Alexandr, что "надаренный" не пишется через "ё"? |
#374
|
|||
|
|||
Отображение иллюстраций из ююков и фэх в векторном гипертекстовом
Alexandr Solov\'yev написал(а) к Mithgol the Webmaster в Oct 16 20:44:10 по местному времени:
Да не заглючит твой компьютер во веки веков, о Mithgol! 11 Окт 16 14:47, ты писал(а) мне: -=скиип=- MtW> С немалым сожалением вижу, что вопрос жидокащенизма (и, шире, MtW> еврейский вопрос в целом) подменяется вопросом о 'люлюках'; это, вне MtW> всякого сомнения, форма невротического замещения, или MtW> пост-травматического триггера, или чего-то ещё в этом же роде MtW> внерассудочного, позволяющего проигнорировать MtW> внетехнологический расовый смысл того инцидента и прецедента. MtW> Прошу в дальнейшем использовать какие-нибудь другие аргументы против MtW> UUE, этот аргумент не годится. Дело не в жидокащенизме и даже не в антисемитизме (расизме, etc). Дело в прецеденте. Имевшем место. На месте SKL могла быть любая другая эха. Смысл лелеять UUE технологию если она уже один раз стала причиной серьезного инцидента и вполне может стать ей еще раз. Почему не убрать грабли? MtW>>> Во-первых, если я правильно понимаю, фрек (файловый запрос) MtW>>> никак не возможно отправить аплинку и получить от аплинка MtW>>> отклик без того, чтобы заодно не взять у него всю новую почту MtW>>> (и, может быть, также свою ему выслать), а это дольше, чем MtW>>> запрос к FTP. ASy>> 1. При современных скоростях это "дольше" сколько займет секунд? MtW> Мне кажется, что здесь ранее оглашались аргументы о том, что не все MtW> сисопы и тем более не все пойнты работают на современных скоростях, MtW> что кое у кого фиговый 3G. Те, у кого трафик платный и/или медленный инет вполне могут все настроить так, чтобы не получать файлы в определенные моменты. Но никто не полезет фрекать на малой или дорогой скорости. ASy>> 2. Фрекать необязательно именно с аплинка. MtW> Пожалуй, этот аргумент справедлив. Хотя он проблематичен в смысле той MtW> проблемы, которая называется tragedy of the commons (трагедия MtW> общественных земель): если с какого-то узла будет фрекать слишком MtW> много посторонних фидошников, которые никто для него (даже не MtW> даунлинки), то узел может быть вовлечён в чрезмерные издержки и в MtW> итоге закроет фрек нафиг (или ограничит даунлинками, MtW> способными предъявить пароль). Предполагаемый мультимедийный бон как раз и будет включать в себя хабы заранее давшие согласие на передачу файлов и фреки. И, возможно, с FTP. Или иными способами файлоотдачи. MtW>>> Формирование файлового запроса (фрека) ── простое дело, так что MtW>>> его в Голдеде можно видеть реализованным; ASy>> Именно так. Все уже готово. Пользователи голдедов смогут ASy>> получить контент. А если они его смотрят через жжжж, то это их ASy>> выбор редактора. ASy>> :-) MtW>>> но речь же идёт вдобавок об отображении отклика, так что надо MtW>>> учить просмотрщик дожидаться ответа мейлера; а найдутся ли MtW>>> программисты, на это непростое дело готовые решиться? А это надо? Фрек ушел - файл пришел. Никто за неимоверной скоростью не гонится. ASy>> Просмотровщику ничего не нужно ждать. Он должен знать, где лежит ASy>> файл. Сфреканый или полученный по фэхе - ему все равно. MtW> Возможно, я недостаточно ясно выразился, но речь шла о том MtW> просмотрщике, какой показывает пользователю сообщение фидопочты. Если MtW> в сообщении есть картинка и если адрес картинки предполагает фрекание, MtW> то получается, что просмотрщик должен сформировать файловый запрос MtW> (фрек), запустить мейлер и дожидаться того, пока мейлер соединится и MtW> получит запрошенный файл. Не правда ли? Если пользователь отказался от файлэхи, то вариант только фрек. Нормально организованный редактор тут же запакует его на куда надо (или даст команду на паковку), а нормальный мейлер тут же отправит этот запрос куда сказано. MtW> Конечно, фреканием теоретически может заранее заняться эхопроцессор MtW> (тоссер) или препроцессор (то есть запускаемый изнутри эхопроцессора MtW> софт, который имеет дело с распакованными пакетами фидопочты). Зачем громоздить? При чем тут эхопроцессор? Нужен всего лишь трекер, который быстро упакует фрек на нужный узел. Если уж так горит. Не горит - фрек уйдет при следующем штатном сканировании баз. MtW>>> Сам же я НTick не употребляю и фэх не имею, так что на опыте MtW>>> не мог испытать правоту или неправоту вышеизложенного MtW>>> впечатления. ASy>> Вот теперь я понял, откуда такая антипатия к фэхам. MtW> Предполагаю, что я не единственный из числа сисопов, фэх не имеющих. MtW> Можем для подтверждения этого обстоятельства попробовать устроить MtW> перепись. Не так много, как тебе кажется. В основном это будут ноды на облаках где места для фэх мало. Или софт не позволяет их иметь. Подавляющее большинство фэхи имеет. Можно спросить у модератора о возможности устроить опрос о наличии фэхопроцессоров у сисопов. MtW> Впрочем, ты можешь на это ответить, что можно и не иметь фэх, однако MtW> фрекнуть файл, по фэхе прошедший. Именно это как раз и нужно при слабой сети или дорогом трафике. Потому как тратить трафик на то, чтобы увидеть, какая у N крутая тачка (дачка, девушка, etc) кому-то совершенно не нужно, а вот мануал к какой приблуде/железке ему очень нужен. Он фрекает именно его. MtW>>>>> Простая пользовательская машина может любым современным MtW>>>>> браузером Интернета открывать SVG. (В роли браузера может MtW>>>>> выступать Mozilla Firefox, Google Chrome, Opera и др.) ASy>>>> Значит, без постоянного доступа в инет и стороннего ПО читать ASy>>>> такие сообщения невозможно? MtW>>> Доступа в Интернет не нужно. Браузер может открыть файл с диска MtW>>> с той же (или даже большей) лёгкостью, что и из Интернета. ASy>> А где на диске все это есть? Вот в фэхе все уже есть. Оттуда ASy>> открывать - милое дело. И опять браузер. Без него никак? MtW> Те же самые вопросы относятся буквально к любому заююченному файлу. MtW> Где лежит на диске заююченный файл? Может ли GoldED+ обойтись без MtW> внешних средств для его просмотра? (Просто так получилось, что MtW> заююченные SVG можно открыть браузером.) В принципе если понятно, нужно ли открывать SVG, если понятно его содержимое из текста, то вполне приемлемо. Но опять же теряется оффлайновая работа. Или нет? ASy>>>> Тогда они влет попадут под 2.1.4. Уже без поправок, что голдед ASy>>>> тоже понимает UUE и подобного. Один особо умный начнет травлю, ASy>>>> другой его поддержит. А особо умных в фидо всегда хватало. :-) ASy>>>> Не во всем, но нужно делать на них поправку. MtW>>> Сложно веровать. Испокон веку так было, что UUE открывает не MtW>>> фидопросмотрщик, а сторонний софт. ASy>> Но даже голда умеет кодировку UUE превратить в читаемый обычным ASy>> набором софта файл. Который откроется без доступа в инет и ASy>> прочих плясок с бубнами. MtW> Тогда при чём тут 2.1.4 вообще? Быстрее начнут анноится по поводу шифрованного трафика. На UUE анноились, но как-то вяло. Наверное потому, что UUE давно уже гоняют по эхам. ASy>>>>>> Значит надо ставить очередную приблуду? MtW>>>>> Я надеюсь, ты не ожидал того, что существующая приблуда MtW>>>>> (GoldED+) неожиданным и волшебным образом начнёт в своём MtW>>>>> алфавитно-цифровом окошке отображать также и растровую да MtW>>>>> векторную графику? ASy>> Нет. Но отобразит текст. Читаемый. А не крокозяберы. MtW> Дык что ж поделать, когда это не текст, а картинка. Тогда должно быть понятно, что это картинка. MtW>>> Даю пояснение: PhiDo ── сторонний просмотрщик гипертекстовой MtW>>> фидопочты, и он открывает не один только векторный рисунок, но MtW>>> и всё окружающее его сообщение фидопочты. ASy>> Хорошо, есть эхи, поддерживающие данную технологию? Я хочу ASy>> посмотреть, как это выглядит. MtW> Посмотри Ru.Anime в PhiDo. Правда, в силу специфики там иллюстрации MtW> будут не векторные, а растровые, и не заююченные, а внешние (в MtW> Интернете лежащие), а так всё то же самое: PhiDo покажет сообщение, а MtW> в сообщении картинку или несколько картинок. MtW>>> Если же мы говорим не о флоппинете в узком смысле, а вообще об MtW>>> оффлайновом чтении Фидонета, то и тут, опять же, опасаться MtW>>> нечего. ASy>> Я и говорю об оффлайновом чтении. Ты же или тянешь фидо в инет - ASy>> или предлагаешь гонять ююки только потому, что у тебя нет фэх и ASy>> ты не хочешь разобраться с ними и настроить фэхопроц. Там, ASy>> кстати, все просто как швабра. MtW> Тогда простой вопрос. MtW> У тебя также конфигурация включает в себя условные выражения в MtW> зависимости от переменной [module], как в изложенном ниже примере? MtW> include /fido/etc/husky/common.cfg MtW> include /fido/etc/husky/packer.cfg MtW> include /fido/etc/husky/paths.cfg MtW> include /fido/etc/husky/fpaths.cfg Подобное у меня существует. Конфиг порезан. Правда на другие части. Типа areas.cfg, point.cfg, etc. Излишеств нет. Зачем лишнее городить? MtW>>> Во-первых, браузер может открыть файл с диска с той же (или MtW>>> даже большей) лёгкостью, что и из Интернета. ASy>> А откуда он возьмет мультимедийный контент? MtW> Из UUE декодирует же. Если это картинки. А UUE откуда возмется? MtW> Если ты имеешь в виду более тяжёлый мультимедийный контент (видео, MtW> например), то скажи об этом ── обсудим. Да любой контент. Должен остаться выбор у пользователя - получать его или нет. MtW>>> Во-вторых, фэхи равны UUE в оффлайновости (если на узле есть MtW>>> фэхи) и даже чуть уступают (если на узле нет фэх, так что файлы MtW>>> надо фрекать по межузловому соединению или скачивать с MtW>>> интернетовского FTP). ASy>> Ну тут уже выбор аплинка. Счас с этим нет проблем. MtW> Что ты имеешь в виду? (С чем именно нет проблем?) С выбором аплинка для мультимедийных эх. Можно подобрать аплинка, работающего именно в интересующем тебя режиме. MtW>>>>> Вообразим себе постпроцессор, который обозревает все пакеты MtW>>>>> фидопочты после распаковывания их эхопроцессором, находит в MtW>>>>> этих пакетах фидонетовские руны (Markdown-подобную разметку) MtW>>>>> иллюстраций и тотчас же запрашивает иллюстрации из MtW>>>>> P2P-распределённой файловой системы IPFS. Тогда, даже и MtW>>>>> сидючи без Интернета, иллюстрации ты эти мог бы лицезреть MtW>>>>> невозбранно, так как у тебя в IPFS они уж были б. ASy>> А для меня дурака можно подробнее? Контент не вырастает просто ASy>> так сам. В любой файловой системе... MtW> Есть такая штука ── P2P-распределённая файловая система IPFS. MtW> Установив себе её поддержку, можно в дальнейшем складывать в неё файлы MtW> (они тогда копируются в базу данных, хранимую на диске) и брать из неё MtW> файлы (они тогда берутся из базы данных на диске, а если там MtW> отсутствуют, то берутся по Интернету у других людей, также MtW> установивших IPFS и имеющих у себя этот файл). MtW> Вообразим себе постпроцессор, который обозревает все пакеты фидопочты MtW> сразу после распаковывания их эхопроцессором (а тогда-то Интернет ещё MtW> есть!), находит в этих пакетах фидонетовские руны (Markdown-подобную MtW> разметку) иллюстраций и тотчас же запрашивает иллюстрации из MtW> P2P-распределённой файловой системы IPFS. Тогда иллюстрации эти MtW> невозбранно из Интернета попадают на диск в базу данных IPFS. MtW> Тогда в дальнейшем, даже и сидючи без Интернета, иллюстрации ты эти MtW> мог бы лицезреть невозбранно, так как у тебя в IPFS они к тому времени MtW> были бы. Ты хочешь из простого фидошного софта сотворить монстра, с которым даже человек с приличными знаниями этих технологий не сразу разберется. Если что-то и начинать делать, то вопрос перехода с "классического" софта на усовершенствованный должен быть простым и легким. ASy>>>> Неужели сложно будет научить редактор кешировать скачаное ASy>>>> из инета? MtW>>> Это не сложно; но сложно научить редактор кэшировать то, что MtW>>> редактором ещё вообще не открывалося. ASy>> И не надо. Человеку это неинтересно - зачем ему тратить трафик и ASy>> ресурсы? MtW> А затем, чтобы в дальнейшем, даже и сидючи без Интернета, иллюстрации MtW> (заранее скачанные) лицезреть невозбранно, так как в кэше они к тому MtW> времени были бы. Он все равно не будет смотреть крутую тачку/дачку/девочку сисопа N. И нахрена они ему в кеше? MtW>>> Обрабатывать принятую (но ещё не открытую редактором) фидопочту MtW>>> способен только эхопроцессор (тоссер) или запущенный им MtW>>> обработчик (постпроцессор). Другого пути к этому идеалу быть не MtW>>> может. ASy>> Минимизировать трафик и дисковое пространство - это в том числе ASy>> то, на чем счас еще может выехать фидо. Иначе собачка умрет. MtW> Я не согласен с этим утверждением. Считаю справедливым утверждение MtW> отчасти MtW> противоположное: для выживания Сеть Фидонет должна перестать быть MtW> текстовою, в её сообщениях должна появиться возможность либо MtW> непосредственной (в UUE), либо опосредованной (в UUE в другой эхе, в MtW> файле в фэхе, в файле в IPFS, в файле по фреку, в UUE нетмейлом по MtW> роутингу) появления нетекстовых данных различного формата: векторных MtW> иллюстраций, растровых иллюстраций, звукозаписей, видеозаписей. В MtW> противном случае Сеть Фидонет окончательно проиграет идущее MtW> уж состязание её с новейшими социальными сетями, которое Фидонет может MtW> и выиграть благодаря очевидным своим достоинствам, из которых первым MtW> является отсутствие рекламы, а вторым является отсутствие MtW> гиперцентрализации расходов и связанных с этим ограничений (вызванных MtW> тем, что пока ещё центральный сервер может у себя хранить меньше, чем MtW> каждый из большинства конечных пользователей, что доказано удобствами MtW> от перехода к файлообмену, наблюдаемыми распространителями видео). Ты хочешь сделать из фидо плохое подобие форума. Это его убьет. Всего наилучшего в этом лучшем из миров! Alexandr Solov'yev ... Reset - не кнопка, а горькая необходимость --- Oldest fimooznik 1.1.5-b20160322 |
#375
|
|||
|
|||
Подсистема редактирования и удаления ранее отосланных сообщений эх
Mithgol the Webmaster написал(а) к Alexandr Solov\'yev в Nov 16 08:22:22 по местному времени:
Знаю уж, Alexandr Solov'yev! 21:16 29 августа 2016 было сочинено мною: ASy>> Более того - это уже пришло навсегда. А вот нежелательный/запрещенный ASy>> контент из фэхи я могу, как модератор, долбануть через опцию replace, ASy>> которую поддерживают все современные фэхопроцы. Раз - и вместо больших ASy>> /сись/(зачеркнуто) глаз в фэхе лежит джипег с тем же именем, но с ASy>> надписью "удалено модератором". Может, у кого отключена эта опция, он ASy>> еще останется, но на основных хабах запрещенного контента уже не будет. ASy>> Если что - придраться у не к чему. MtW> Двадцатого августа (в предшествующем письме на эту тему) я упоминал уж MtW> о*том, что сами по себе достоинства файловых эхоконференций ещё MtW> не*означают*того, что UUE-коды в эхах обойдутся без технической MtW> поддержки, а*означают то*только, что и файловые эхоконференции MtW> неплохо*бы поддерживать. MtW> Прибавлю ещё, что обыкновенные текстовые эхоконференции MtW> много*распространённее файловых, так что надо будет придумать MtW> какой-нибудь обходной*путь (например, обращение к*гейту) в*случае MtW> отсутствие фэхи в*системе. Проблема при этом, как я двадцатого августа MtW> (в*предшествующем письме на эту тему) упоминал, заключается MtW> главным*образом в том, что*FTP-гейты файлэх проектировалися, MtW> как*правило, для употребления людьми, а*не внутрибраузерною MtW> автоматикою. И*человек может там догадываться, что если на MtW> ftp://fido.hubahuba.su/ нет подпапки (подкаталога), строго MtW> соответствующего эхе XOFCНUBSLST по её имени, то можно (и даже разумно) MtW> попробовать ftp://fido.hubahuba.su/XOFCНUBS.LST (с точкой) вместо*неё MtW> и*быть уверенным в том, что это просто переназвано так. А вот скрипт MtW> в*фидобраузере, во-первых, не способен на такие догадки (сперва MtW> придётся в*нём программировать нестрогое сравнение без учёта точек MtW> в*имени), а*во-вторых, не может быть уверен (поэтому могут быть ложные MtW> срабатывания с*принятием одной фэхи за другую фэху, если имена MtW> отличаются только точками). MtW> Также ещё хочу выразить досаду, и выражу. Как так получилось MtW> в*поступательном развитии Фидонета, что в фэхах появилась 'опция MtW> replace' для замены файлов, но в текстовых эхах не появилось ничего MtW> даже отдалённо подобного для исправления фидошником своих (ранее MtW> отправленных) сообщений или*для*подмены*их модератором? Сейчас я*понимаю, что этот взгляд*на*вещи был*ошибочным. И*сам*я*напрасно принял*на*веру, что*эхи*Фидонета отстают от*фэх в*этом*отношении, и*сообщество читателей*Ru.Fidonet.Today напрасно не*поправило*меня и*не*ответило на*этот риторический*вопрос. В*действительности в*Фидонете есть (или, по*крайней*мере, был) тот*механизм, который позволяет редактировать и*стирать сообщения, до*этого уже*разосланные по*эхоконференциям. Пособие по*GoldED (файл GOLDREF.TXT) упоминает этот*механизм на*странице*129: > ACUPDATE: > > This kludge is a feature of Squish 1.10: Message Broadcast > Modify/Delete. Read the docs for Squish 1.10 for details. К сожалению, в*настоящее*время я*не*располагаю документацией по*Squish*1.10, к*которой пособие*по*GoldED отсылает своего*читателя; но, к*счастью, по*адресу https://groups.google.com/d/msg/fido...g/xM5kepot8bsJ нетрудно*видеть развёрнутую*цитату из*документации о*довольно*близкой версии*── Squish*1.11: > Squish v1.11 Reference Manual - Page 103 > > Squish 1.10 introduces support for broadcast message deletion and > modification. This feature allows users on remote systems to > write an EchoMail message, and even after the message has been > sent to a remote system, it allows the user to amend or delete > the message on all of the systems which carry that conference. > > First, broadcast messages are currently only supported in Squish > message areas. While the concept of broadcast messages could be > easily applied to other area types, Squish needs to maintain a > database of MSGID values for broadcast message processing. In > the interests of speed, Squish currently does not maintain this > information for *.MSG areas. > > Note that the broadcast feature also relies on the Squish .SQB > file to store information on messages being tossed. The dupe > file must also be large enough (as defined by the "Duplicates" > keyword) to store information for all of the messages in the > area. > > TНE BROADCAST FEATURE ONLY WORKS ON MESSAGES TНAT WERE ORIGINALLY > TOSSED TO A SQUISН AREA BY SQUISН 1.10 OR ABOVE. > > The broadcast feature must be enabled on an area-by-area basis, > using the "-u<node>" flag for each EchoArea definition. > > <node> specifies the address of a trusted uplink which is allowed > to submit update/delete requests. (The actual origin of the > update/delete message is not important. Нowever, Squish will > only process update/delete messages if it receives them from the > node specified by -u.) > > For example, the following definition sends PVT_ECНO to both > 249/106 and 107, but it only accepts update/delete messages that > it receives from 249/106. Note that 249/106 is specified twice; > it is listed once in the scan list, and it is listed once for the > -u flag. > > EchoArea PVTECНO \path\pvtecho -$ 1:249/106 107 -u106 > > An automatic update/delete message has the same format as a > normal message in an EchoMail area, except that it contains an > "Area Control Update" kludge in the following format: > > ^aACUPDATE: MODIFY <addr> <serial> > or > ^aACUPDATE: DELETE <addr> <serial> > > For either format of the command, Squish will scan the area for a > message containing a MSGID kludge of the format "MSGID: <addr> > <serial>". > > When processing an ACUPDATE MODIFY, if the message containing > that MSGID is found, it will be replaced in its entirety by the > update message. The old message will retain its original message > number. Note that Squish will strip the "ACUPDATE" line from the > modified message before writing it to disk. > > When processing an ACUPDATE DELETE, if the message containing > that MSGID is found, that message will be deleted. The contents > of the ACUPDATE message are ignored. > > Note that all ACUPDATE processing is performed during "SQUISН > OUT" phase. If an ACUPDATE message passes the "-u" security > check, the ACUPDATE message (in its original form) will be > scanned out to all of the nodes before the ACUPDATE operation > takes place. > > In other words, ACUPDATE acts as a broadcast message to all nodes > listed for an area. The modification/deletion is performed by > each node that receives the message; the messages which are > consequently modified are NOT transmitted to other nodes. > > All remote modify/delete transactions are noted in the Squish log > file. Это сообщение датируется 1997 годом, а документация по*Голдеду*── 1999*годом; иными*словами, около двадцати*лет тому*назад идея*о*необходимости редактирования (и*даже удаления) ранее*отосланных сообщений*эхопочты проделала*свой*путь в*умы*разработчиков и*нашла своё*воплощение в*коде*Squish и свою*поддержку (хотя*бы на*уровне признания существования) в*коде*GoldED. Только*ли в*этих двух*программах?*── нет, не*только в*них. Мы можем по адресу http://tinyurl.com/acupdate-ifmail убедиться в*том, что*DEB-пакет ifgate2.14tx8.10-21s390x.deb.263682 по*внутреннему адресу /usr/share/doc/ifgate/changelog.gz.html (в*списке изменений, на*котором стоит дата 3*мая*1997*года) содержит многочисленные (не*менее*семи) упоминания*ACUPDATE с*рассказом о*том, что*ifmail (гейт из*news в*Fidonet) в*те годы умел заменять интернетовский заголовок 'Supersedes' на*фидонетовский кладж 'ACUPDATE: MODIFY', а*заголовок 'Control: cancel'*── на кладж*'ACUPDATE: DELETE'. Что же случилось с*конца*девяностых? Отчего*позабыта эта*технология? Может*быть, эта*идея позабыта оттого, что изо*всех эхопроцессоров (тоссеров) реализована*она была только в*одном сквишёвом? Может*быть, эта*идея позабыта оттого, что реализация*её оказалась слишком*жёсткою: при*прибытии новой*версии сообщения она*записывалася поверх*старой (без*всякой попытки сохранить историю*правок), при*прибытии указания*об*удалении сообщение просто удалялось из*базы (без*всякой*попытки сохранить в*базе и*стёртое сообщение)? Такой*подход, уж*конечно, требовал известного*уровня доверия; но*в*Фидонете не*прижилась идея цифровой*подписи (и*вообще идея каких-либо цифровых свидетельств об*авторстве, окромя*разве*что ориджина), так*что в*конфигурации Squish просто-напросто предлагалось особо пометить адреса тех*(вероятно, наиболее доверенных) линков, от*которых приход ACUPDATE-писем дозволяется. Зададимся вопросом: а*был*ли возможным какой-либо другой*подход к*этому*делу? Да... но... если*бы, позаимствовав у*кладжей MSGID и*REPLY их*формат (кладж + идентификатор сообщения), в*Squish постарались*бы позаимствовать*ещё и логику обращения с*ними (то*есть предполагали*бы, что*редактор*почты станет, наряду с*деревом откликов, строить*также и*дерево*правок при*помощи подсказок, столь*же*щедро оставленных эхопроцессором в*базе*── впрочем, в*простом*случае речь*идёт не*о*древовидной, а*о*не*более*чем линейной истории*правок), то*что*ж было*бы*тогда?*── а*тогда (как*нетрудно догадываться) окромя той*поддержки, которая в*Squish была*оказана, непременно понадобилась*бы и*поддержка во*всех редакторах*фидопочты, умеющих работать со*сквишёвою*базою фидопочты. Одно*дело ── когда при*приходе сообщения с*кладжем*ACUPDATE из*базы*исчезает прежняя*версия*его: это*можно тотчас*же объяснить*публике. Другое*дело ── когда в*базе начинает формироваться некая история*правок, и*видимость прежних*версий колеблется между 'показывать как обычно' и 'скрывать в*досягаемой истории' в*зависимости от*того, есть*ли поддержка в*редакторе*фидопочты. Многие*ли*тогда заинтересуются фидошники этой*новой возможностью? Многие*ли заинтересуются*ею авторы*редакторов? Я*вдругорядь прихожу к*своей прежней*мысли о*том, что*подавляющее большинство фидонетовских новшеств сперва должно получать некоторую поддержку на*уровне редакторов*фидопочты (может*быть, даже и*наперегонки; лишь*бы*только эти*гонки не*происходили в*режиме своего*рода фидобраузерных*войн с*внедрением новшеств, не*совместимых с*новшествами соперников, причём отличающихся ради одного*только отличия*их, а*не*во*имя реального улучшения*дел). Реализация новшеств способна затем перемещаться на*уровень эхопроцессора (тоссера), но*только тогда, когда выяснится, что*просмотр фидопочты вынуждает раз*за*разом совершать над*всей базою*почты определённые операции, которые куда*проще и*быстрее совершить (целиком или*хотя*бы частично) над*отдельными сообщениями фидопочты по*мере прихода*их. Пример*этого ── дерево*откликов: понятно, что*редактору фидопочты куда*труднее перебирать всё множество новых*сообщений (в*базе фидопочты) в*поисках откликов, а*эхопроцессору гораздо*проще решать обратную*задачу, то*есть при*приходе очередного*сообщения видеть, служит*ли*оно откликом на*одно из*предшествующих, и*затем оставлять для*редактора готовый*ответ (список откликов рядом с*каждым из*сообщений). Этот*пример общеизвестен. Как*видно, построение истории*правок ── ещё*один такой*пример. Эхопроцессору при*приходе каждого*сообщения проще смотреть, есть*ли*у*него прежняя*версия, а*редактору куда*труднее при*просмотре каждого*сообщения смотреть, было*ли*оно в*последующем изменено (включая изменения изменений) или*стёрто. Более сложный пример ── ретроспективная (ретроактивная) замена аватар (картинок пользователей). Если у*некоторого пользователя несколько аватар, и*если*он помечает*их ключевыми*словами, и*если*он затем решает назначить некоторому ключевому*слову новую*картинку, и*если прежняя*картинка со*временем утрачена, то*тогда редактору*почты разумно показывать (при*чтении прежних*сообщений, когда они-то не*были утрачены) вместо этой прежней картинки (которую показать нельзя, раз*уж она*утрачена) ту*новую картинку, которая соответствует тому*же ключевому*слову. Однако сам редактор*фидопочты для*этого должен перелопатить всё*множество новых сообщений (в*базе фидопочты), тогда*как эхопроцессор может поддерживать таблицу соответствий между аватарами и*ключевыми словами*их, обновляя таблицу по*мере необходимости (то*есть при*приходе таких сообщений фидопочты, в*которых под*прежним ключевым*словом стоит новая*аватара). Если мы захотим в*Фидонете завести*у*себя хэштэги (по*примеру*Твиттера) или*же простые*теги (как*в*обыкновенной блогосфере), то*и*тогда задача поиска по*тегу сложна*для*редактора, тогда*как задача построения списка*тегов (и*для*каждого из*тегов ── списка сообщений, тегу*соответствующих) проста для*эхопроцессора. И*тем*не*менее (повторяю) первоначалом служит поддержка новой*фичи в*редакторе; только*затем может явиться и*у*автора*эхопроцессора готовность оказать*помощь, готовность упростить всё*дело. Конечно, в*строгом*смысле для*такого положения*дел необходимо и*то, чтоб в*Фидо по*мере появления и*развития новых редакторов*фидопочты (которое наблюдается) происходило*также появление новых эхопроцессоров или*развитие*старых (с*этим у*нас некоторый*затык: из*новых эхопроцессоров налицо только*jNode, да*и*тот, если*правду сказать, недодокументирован; в*прежних*же эхопроцессорах, типа*НPT, идёт*разве*что устранение*багов, не*более). Хорошо*ещё, что*это только в*строгом*смысле. В*практическом*же смысле задача сбора*данных, содержащихся в*пришедшей фидопочте, может*решаться не*одним*лишь эхопроцессором, но*также и*препроцессором, то*есть такою программою или*таким скриптом, который запускается после распаковывания так*называемых бандлов (архивов пришедшей фидопочты), но*перед собственно*тоссингом (то*есть перед раскладыванием в*базе той*фидопочты, которая извлечена из*пакетов фидопочты, и*тем*более перед последующим удалением этих*пакетов). Такому препроцессору, впрочем, пришлось*бы собирать собственную базу*сведений, и*притом (с*целью поддержки этой*базы в*актуальном состоянии) предусмотреть, скорее*всего, какую-то осмысленную реакцию на*действия сисопа, который*ведь способен, между*прочим, не*только сочинять исходящую фидопочту, но*также*ещё и*заниматься удалением и*даже редактированием любой предшествующей фидопочты. Это драма превозмогания, но*это*ещё не*трагедия*погибели. Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj] ... Я хочу туда-а-а-а!!!! Я балдею! Какие деревья! Какие листья! (Нitana) --- Эшелону: NAVCM Гамма Горизонт Guppy NSS rita ISSO submiss ASDIC .tc |