shaos> А зачем отдельно, если оно уже есть - никаких новых полей ненадо т.к. всё уже прям тут - бери и используй как говорится :)

Я там выше сообщение написал про то как можно сделать редактирование. ii://sZbskcy7huzEVJlsSDIF

То-есть, если считаем msgid настоящим хешем, так уже не сделать.

Мне интереснее, конечно, эту проблему решить.

AL> Не в первый и, думаю, не в последний раз, кого-то посещают мысли об нецелевом использовании идентификаторов. Я тоже предвзято отношусь к редактированию сообщений, но исключительно потому, что это ломает обмен. Получается, что на разных узлах лежат разные версии одного и того же сообщения.

Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://sZbskcy7huzEVJlsSDIF

Вроде в таком варианте новые версии сообщения будут распространяться.

hugeping> Да, я там сделал попытку предложить что-то (как мысленный эксперимент): ii://sZbskcy7huzEVJlsSDIF

hugeping> Вроде в таком варианте новые версии сообщения будут распространяться.

То-есть, основные мысли:
1) если видим что что-то на станции в этой эхе поменялось - всегда делаем полный фетч (адаптивный фетч в топку)
2) во время фетча учитываем не только id, но и ревизию сообщения. Всё это для простоты может быть частью msgid (но может и не быть)

shaos> лучше версионность делать иными средствами имхо - поверх и сбоку

Вот и проверку подлинности можно поверх и сборку. :)

Кроме шуток, да, я думал о "сбоку". Но тогда, получается, мы должны сначала получить id сообщений эхи. А потом, ревизии но в полном соответствии с id. И тогда непонятно вообще зачем 1й вызов? Ну то-есть оно может быть сбоку, да, но ответ всё равно будет включать в себя и id и rev. Ну например:

JOHemYNZRC8Uo9QwAYQU:1

Мне кажется редактирование сообщений неплохо в "базе" иметь, всё-таки.

> т.к. оно будет нужно только для очень особенного типа сообщений

Понимаешь, у всех у нас своё "особенное" понимание. Я считаю что ii следует понимать просто как распространение текстовых сообщений. Что ИМЕННО в этих текстовых сообщениях - не наше дело. Кто-то считает, что это "мессенджер", кто-то - форум, а кто-то в блогах пишет....

hugeping> JOHemYNZRC8Uo9QwAYQU:1

Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

hugeping>> JOHemYNZRC8Uo9QwAYQU:1

hugeping> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

hugeping>>> JOHemYNZRC8Uo9QwAYQU:1

hugeping>> Тогда такой вариант. Всё как было, но если сообщение отредактировано то в u/e/ придёт вот такая строка с доп ревизией (после :). Эту ревизию можно зашивать в теги самого сообщения и хранить в базе.

hugeping> Гм. На практике, редактирование сообщения - добавление новой записи в бд. Так что тут не все так просто.

Да нет, вроде нормально... Редактирование сообщения - это выпуск msgid с новым полем rev. Это на усмотрение ноды как именно отразить это в бд. В ii-go это дописывание новой инфы которая "перекрывает" старую. В sql это может быть тупо запись в бд. Требовать чтобы запись добавилась в конец запроса u/e наверное нецелесообразно.

shaos> Ну вот поэтому все редакции "особых" сообщений должны идти как отдельные записи в списке хешей

Это слишком сложно и нецельно. Ладно, я тогда не буду развивать тему. Существующий стандарт хотя бы какая-то твердая почва

revoltech> Sad but true. Хотя мне, наверное, было бы достаточно корректно работающего ii. Просто по ходу дела выяснилось, что это ближе к мифу или оксюморону.

Драматизировать тоже не стоит. Я помню, когда делал для микроконтроллера клиента gemini тоже сталкивался с "разночтением" стандарта. Точно сейчас не помню, но кажется это было связано с относительными ссылками или что-то вроде того. Но это не мешает gemini быть живым.

Да, x/c похоже мало кто соблюдает в буквальном смысле. Но в остальном, я не вижу особых отклонений от стандарта. Ваши желания того, чтобы msgid совпадал с хешем сообщений -- никогда не было требованием. Как правильно тут писал Рома, иногда мы даже заполняли недостающую часть "заполнялками" итд. Хеш - это просто естественный способ создать уникальный идентификатор.

Все реализации, которые живы на данный момент обмениваются друг с другом вполне себе нормально. Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...

hugeping>> Ну, хочется видеть idec другим -- никто не мешает разрабатывать свои варианты...

tuple> Жаль при этом происходит дробление сообществ на всё более мелкие части...

Примерно как с gemini. Одному не понравился tls, второму -- отсутствие динамики... И понеслась. Тем не менее большая часть людей осталась на gemini. Я тоже на нём остался, и не жалею. Но тут как бы дело личное. С idec же "сообщество" -- слишком громко сказано. :) Но опять же, сомневаюсь что обмен по ii/idec кто-то из текущих нод будет выпиливать.

revoltech> * Раз GET /list.txt всегда был в ii, надо его описать в базе, а не в расширениях.

В стандарте написано что это расширение. Значит - расширение. Было оно в ii или нет, не важно. Так как стандарт описывает idec. Сейчас ноды написаны так, что декларируют list.txt в расширениях. Для обмена list.txt не является обязательным. Так что не вижу причин переписывать стандарт.

revoltech> * Раз айдишники в виде волшебного шопопало до сих пор проскакивают, надо указать, что алгоритм их генерации рекомендован. И указать правила замены на A-z, которые все ноды между собой понимали бы.

Рекомендованный алгоритм описан в стандарте. Но проверять на его соответствие -- в стандарте такого нет. В стандарте указаны не A-z, а A-Z. Но, подумав, не могу сказать что это тоже требует изменения стандарта. Ну, алгоритм отличается немного от ii, и что?

revoltech> * Раз счётчики де-факто могут убывать, надо убрать ту приписку «Важно: параметр неубывающий».

С счётчиками я не знаю что делать. Возможно, надо признать что этот стандарт большинство не исполняет и всё.

revoltech> Ну и так далее.

А что ещё? Ну, переводы строк?

tuple> Странно отрабатывает сортировка в профиле https://club.hugeping.ru/from/btimofeev/7 . Если промотать вниз, то там видно два сообщения, которые написаны в 2020-м году, а выше идут из 2024-го.

Это следствие того, что эху retro.talks создали только что. Я удалил у себя oldpc и зафетчил retro.talks заново. В итоге, сообщения пришли как бы "только что". Для станции они - новые.

ii-go в данном случае показывает сообщения по мере их прихода на сервер, а не в соответствии с датой создания автором. Так что, получили то, что получили...

revoltech> В extensions.md: написано: «Здесь описаны расширения протокола, являющиеся основным отличием IDEC от ii.» — и там перечислен в том числе /list.txt. Это читается так, как будто IDEC от ii отличается в том числе /list.txt, т.е. в ii его не было.

В ii не было просто самого механизма расширений. В любом случае, смысл менять стандарт я не вижу. Иначе придётся требовать наличия list.txt как обязательного компонента.

revoltech> А то, что если IDEC декларирует обратную совместимость, то одно и то же сообщение не должно приводить к разным айдишникам в разных версиях стандарта.

id создаётся один раз в момент создания сообщения, для обмена нет необходимости его где-то пересчитывать. Главное, уникальность. Вероятность коллизии крайне мала, при условии что id считается какой-то хорошей хеш функцией. Хотя, думаю, можно в принципе и тупо рандом брать, думаю на наш век этого точно хватит.

revoltech> Как и многое другое оттуда же.

Что именно? x/c - да. msgid - нет, нет такого требования. Хеши и не должны совпадать. Но ты пишешь "многое другое". Где пруфы?

Мне кажется ты совсем не читаешь то, что я тебе пишу. Прекращаю это бессмысленное занятие. :)

revoltech> Про переводы строк как минимум нужно явно указать, что разделитель строки — строго LF, да. Пока вроде всё, но вычитать остальное не мешало бы.

На самом деле с переводами тоже не все просто. Я когда написал фильтр получил ещё несколько сообщений с \r где-то в теле. Я стал их резать при записи в БД. Кстати, ещё один источник того, что хеш может отличаться. В общем, idec и ii не требуют совпадений при пересчёте хеша. Пересчёт вообще не должен нигде проводиться.

Так, кажется я понял что выносит мне мозг.

Сообщение ii://wCtCSY0AQJBPZgD7zwYS от revoltech с subj: Re: Стандарт
Поле repto указывает на: ii://rgxK6d4FLFZpuzawHltM с subj: Re: Неожиданное наблюдение

Зачем так делать? :)

AL> Итак, меня тут назначили главным по стандарту. Моё предложение такое: убрать фреки, убрать фэхи, убрать счётчики, оставить только e/, m/, u/e (со слайсами), u/m, u/point, u/push, list.txt, blacklist.txt. Остальное выпилить нафиг.

А ты знаешь, подумал... Вообще, мне нравится. Без x/c можно жить, тем более если list.txt в базе будет.

hugeping> Зачем так делать? :)

А началось это кажется здесь: ii://wCtCSY0AQJBPZgD7zwYS
И здесь: ii://0Lo8T5IAlUzzV0A2pgzy

Вообще, это нормально менять тему во время ответа, но всё-таки тут явно что-то сбоит и Re: Стандарт взят откуда-то по ошибке... А я всё это смотрю на два одинаковых Subj, но попадаю в разные топики.

revoltech> Сам же просил все связанные со стандартом вещи начать тегировать как ответы на сабж «Стандарт». Или нет?

Ага, теперь понял откуда это. Дело в том, что топики отслеживаются по цепочке repto, а не по subj. Ну, главное теперь я понял, что это не баг.

Я то ожидал что мы перейдем в Стандарт. Для этого надо отвечать на сообщения там, а не в той теме про невидимые эхи.

ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?

Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

AL> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL> PS: Перед окончательной публикацией дождусь реакции hugeping.

Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?

С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...

Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.

P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)

hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1

revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?

Не делал никогда так, но в стандарте написано что нет.

/u/e/area.one/area.two/0:10 запрашивает первые десять сообщений в индексе, а /u/e/area.one/area.two/-10:10 запрашивает последние десять сообщений в индексе.

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех запросит. В стандарте есть пример, я его прислал. Но ты похоже его даже не читал.

https://club.hugeping.ru/u/e/idec.talks/std.hugeping/-1:1

Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
Но сдерживаться мне всё тяжелее конечно...

Понимаю, что меня не воспримут, всё-таки напишу.

Подумайте, что за задачи вы решаете?

Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Видимо, предполагается что "умный" админ будет настраивать фетч таким образом под станцию, что задаст разные лимиты для эх разной наполненности? Зачем этот ужас? Придумайте, как в реальности вы будете это использовать?

Потом, Рома трясёт своим ?sf=hash - как замену слайсов. На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим) и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку. Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.

Потом постоянные намёки на то, что нам нужно обязательно забрать всё одним запросом. Причём, неявно подразумевается что это благая цель которую все разделяют... ЗАЧЕМ?? У меня фетчер вообще забирает по 12 кажется msgid за раз, но он, наверное, самый быстрый из всех реализаций что я видел. Можете скачать ii-go и сделать полное клонирование моей станции и написать, сколько это заняло времени.

Про ограничение на запрос. В лучшем случае в стандарт можно добавить рекомендацию про 8кб "стандарт" запроса, который в большинстве случаев совпадает с фактическим положением дел. Но расширение, которое будет показывать этот параметр, который вообще говоря доступен только веб серверу? Сами же простоту и элегантность хотите, нет? По 16 msgid забирать чистоплюство не позволяет? Значит, страдайте! :)

В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.

Моё мнение -- надо замораживать вариант драфта Андрея. А дальше, пилить альтернативный стандарт - если он будет хорош - ну значит его поддержит. Кто-то. Но в таком хаосе и горячке я точно не участник. Мне не нравится русло в которое все свернуло. Но это - неизбежно. Поэтому коммьюнити не будет. Никогда.

shaos> Неа - опять не сработало…

Возможно, потому что в сообщении нет последнего перевода строки ( см: http://shaos.net:8085/ii-point.php?q=/m/DpizUAp7CfgxVznSUul4 )

Только можно тестировать это в другой теме, пожалуйста? :)
P.S. Edited: 2024-10-31 08:53:11

tuple> Как я понял: эти сообщения существуют, но сообщения, которые записаны в их repto, не существуют. Поэтому их веб-морда показать не может, а они есть. Потеряшки?

Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.

hugeping> Возможно, это не очень хорошо. Судя по коду, DecodBundle отбрасывает сообщение если в нём неверный repto. То-есть дело не в веб морде даже. Потом подумаю, что лучше с этим сделать. Пока так.

Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.

hugeping> Да нет, вру. Там проверяется на корректность ID всего лишь. Странно. Проверю.

У этих сообщений repto не соответствует формату. Не 20 символов. Таки сообщения я стал дропать на приёме, после того случая недавнего. Но старые сообщения остались, видимо, битые.

AL>> Зачем ему это понимать?

revoltech> Он может сгруппировать по 16 и получить ошибку на tgi, каковы дальнейшие действия?

Варианты:

1) tgstation считать аномалией и написать админу, чтобы он сделал "стандартные 8k" как рекомендовано в RFC: https://www.rfc-editor.org/rfc/rfc9110.html#section-4.1

It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.

2) Увидев это, задать параметр поменьше для фетча конкретно с tgi и оставить

3) Расширить станд.... ^W тьфу! :)

hugeping>> It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements.

revoltech> Так, может, тогда и в стандарте прописать |(8000 - 5) / 21| = 380 айдишников рекомендованным максимумом для отдачи через /u/m?

Всё-таки, это не аксиома. Тут мы зависим от внешнего фактора. Так что я бы написал что-то вроде:

> При составных запросах следует учесть возможные ограничения сервера на максимальную длину. Поэтому в общем случае запросы следует разбивать на части ... итд

Главная мысль в том, что фетчер всё равно должен содержать в себе логику разбивки на запросы. А размер "пачки" -- дело второе. Я бы вообще > 16 или 32 не ставил бы никогда.

revoltech> Ну вот для случая полного перефетча это как раз издевательство, но пусть, лишь бы нода и 380 поддерживала.

Ну там выше tuple скинул сколько полный фетч занимает времени с моей станции. А ты видел на чём она работает? ;) И сколько там в одном запросе? Так что я по прежнему не вижу проблем. Но раз кому-то очень важно, чтобы в одном запросе шло 380 сообщений, ну пусть так. Но в стандарте я бы явно не фиксировал эти числа. Написал бы про общую проблему.

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

Поэтому я лично пытался придумать что-то, что было бы так же просто как базовый ii, но всё-таки решало те проблемы, которые мне бы лично хотелось бы решить.

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

Но аскетика - дело добровольное. Если каким-то людям эти ограничения тесноваты - они вольны решать эти проблемы так, как они это способны делать. И даже, если они делают это по твоему мнению плохо и топорно, вправе ли ты их за это осуждать?

# Обсуждаемые изменения стандарта idec

Обсуждаемые изменения стандарта - в основном, реакция на взгляд со стороны о двусмысленных моментах. Андрей выкинул из текущего idec то, что посчитал лишним. Так что это упрощение. А то, что было неточно сформулировано - сформулировал. Речь вроде бы и не шла о "принципиально новом" стандарте. То-есть, мера хаоса была уменьшена, не революционно, но тем не менее. В этом и есть его ценность.

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

Ну так возьми и предложи, связанным текстом непротиворечивый стандарт, который по твоему мнению достаточен.

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

В общем, давай конструктивно. Дружно. Корректно! (Мою ноду дети читают!) Предлагай решения если есть что предложить дополнительно или скажи, что тебя устраивает ii в чистом виде, но тогда и не нервничай. Дай нам двигаться своим путём.

AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)

m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.

Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)

Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.

Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.

1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)

2) Выборка, основанная на времени.

Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).

Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?

Что думаете?

tuple> Стоило прийти в idec, как его уже хоронят :)

Не надо вбросов! Давай по существу.

P.S. Ipv4 тоже хоронят давно, но что-то никак. :)

hugeping> Что думаете?

Продолжаю рассуждать. sf=hash становится надёжной, если только мы после последнего фетча запоминаем hash последнего сообщения которое зафетчили и сохранили. Возможно, о таком режиме Рома и говорил, но я до сих пор воспринимал sf=hash совсем по другому. Так что пишу это, если вы тоже воспринимали это по другому...

Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.

Мне, правда, не нравится необходимость хранить эти хеши для фетчей (причём для каждой ноды), поэтому идея с временем нравится больше. Но тем не менее.

shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...

Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...

shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).

Я имел в виду время принятия сообщения нодой, а не время создания сообщения, конечно.

shaos> А ну это сейчас вообще никем не фиксируется

Гм. Действительно, как-то я не подумал об этом. :)

shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…

Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?

shaos> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа

Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью. У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.

Я попытался склеить твои сообщения фрагментные в одно и осознать. Но не смог. На моё сообщение ты как-то очень непрямо ответил. По кр. мере я не считаю что ты меня понял и ответил так, чтобы я понял в ответ. Почему уж это происходит так -- я не хочу разбираться. Давай я перестану тогда тебя беспокоить. Буду заниматься дальше своими делами.

Решил написать сюда, чтобы не потерять.

Несколько лет пользуюсь gnus. И тут, после последнего обновления emacs, часть писем у меня стала отображаться в битой кодировке. В теле письма всё ок, стоит utf-8.

Я уже не помню, как именно удалось локализовать проблему (скорее всего просто трейсил и менял куски gnus на старый gnus из 26 emacs), но вот "волшебная строчка", которая помогла:

(setq nnheader-file-coding-system 'raw-text)

Купил тут МФУ. Специально брал с WiFi, чтобы можно было ставить куда угодно.

Поставил, подключил по USB, включил. Запускаю hp-wificonfig и... Пишет: нет поддерживаемых принтеров.

Ну, начал отлаживаться. К счастью, написано на питоне.

В общем, вот решение:

Файл: /usr/share/hplip/data/models
Ищем строку: model1=HP Ink Tank Wireless 410
После неё ищем wifi-config=0 и меняем строчку на wifi-config=3

Теперь hp-wificonfig увидит принтер и можно будет подключить его к домашней WIFI сети.

P.S. Пишу это сообщение, так как после обновления пакета hplip потерял это изменение и разбирался повторно. :)

Купил в начале карантина два ноута: Acer Apire 3. И надо сказать, очень доволен (дёшево и эффективно). Но на ноуте частенько в 3d приложениях наблюдал битые текстуры. Не сказать, что критично, но -- напрягало. Быстрый поиск ничего не давал. Но в итоге, всё-таки нашлось:

# Переменная окружения
AMD_DEBUG=nodmacopyimage

По этой строчке проблема уже легко гуглится, так что можно за ней следить.

P.S. Следующие компы буду брать на AMD.

tuple> Очень желательно сделать на станции отличие одной страницы от другой в title вкладки. А то в истории браузера сохраняется просто как:

Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

Непонятна схема. Какие машины, где стоят, где концы туннеля итд...

P.S. Сам не настраивал openvpn, но по схеме всё-равно вопросы.

hugeping>> Посмотри сейчас, лучше стало? Правда наверное не все случаи предусмотрел.

tuple> Да, классно теперь. Только https://club.hugeping.ru/echo/all/ отображается как "club.hugeping.ru/echo/all".

Ага, ещё несколько случаев добавил. Если что, пиши. Для меня web ii-go сейчас близок к идеалу. Но иногда что-то меняю по мелочи.

Я всё-равно ничего не понял. Может быть кто-нибудь и ответит. А мне нужно понимать что происходит. Например. Openvpn это два конца. Нужна схема сети, где эти концы находятся в этой схеме. Где сервер и клиент в этой схеме. Интранет/интернет. Наты. Итд. А так, я вообще ничего не понял.

shaos> Если надо чтобы что-то из списка брало по своему, то там надо указать свой "срез" либо волшебное слово all либо волшебное слово last

Просто на всякий случай. В слайсах, установка limit в 0 означает безлимит.

https://hugeping.tk/u/e/idec.talks/0:0 - всё
https://hugeping.tk/u/e/idec.talks/-1:0 - последнее (ну или -1:1)

Привет!

До последнего относился к деятельности Поттеринга с пониманием. Прогресс дело такое. Linux давно уже сложная система, systemd неизбежен -- думал я.

Пока не коснулось моей работы. Несколько лет у нас периодически падала сборка, в момент работы fakeroot. Отлаживали faked, пытались разнести во времени сборки -- результата не было. Наконец, когда за одну ночь сборка упала 5 раз я не выдержал и попытался в очередной раз найти причину.

Помог гугл. Оказалось, что systemd стирает объекты IPC при log-out пользователя из системы. А на систему сборки периодически ломились наши боты, проверяя статус сборки итд.

В общем, RemoveIPC=no в /etc/systemd/logind.conf помог. По крайней мере, три дня уже всё чисто.

Конечно, ошибаются все. Но в данном случае это не ошибка, а осознанное убивание Unix. Ситуация наглядно иллюстрирует тот факт, что когда какой-то Unix компонент занимается не своим делом, найти проблему очень и очень сложно.

Как вообще могло придти в голову стирать что-то там при logout? Удивительно, что /tmp не затирается...

В общем, признаюсь себе честно -- Linux больше не система моей мечты. Я разочарован и удручён. Похоже, Plan9 и BSD системы -- это мой удел на старости лет. Linux -- система для выполнения утилитарных вещей и это моя работа. Но сказать, что мне нравится выбранный курс развития -- категорически не могу. Linux стал слишком "взрослым". Sad but true...

Я после всех этих обсуждений засомневался, а может быть и правда нам нужны множественные слайсы в u/e? Может быть это нужно для адаптивного фетча? Поговорил с Андреем и стало понятно что вроде бы не нужны.

# Идея

Идея, на самом деле, простая. Мы сканируем последние сообщения станции но ровно до тех пор, пока сами не решим - хватит или нет. А решение принимаем на основе анализа полученных msgid (есть они в базе у нас или нет?). В этом отличие от просто фетча последних n сообщений.

# Алгоритм

1. Выбрали N=16, LIM=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:LIM
4. Для каждой эхи в ответе:
- Все отсутствующие msgid добавляем в список, который добавляем в голову msgids
- Если таких сообщений нет или ответ содержит меньше записей чем N (выгребли всё)
удаляем эху из набора elist
5. Набор elist пуст? Да! иди на 10
6. LIM=N, N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/m для всех id из списка msgids

Числа 16 и 1024 тоже эвристические. 1024 - просто способ закончить фетч если мы видим, что адаптивный фетч всё никак не дойдёт до "дна".

# Можно ли проще?

Моя станция работает по-другому. Основное отличие в том, что я делаю запросы -N:1 а не -N:LIM и просто проверяю -- а есть ли у меня это сообщение или нет? Если есть, потом я делаю фетч на -N:N.

1. Выбрали N=16
2. Выбрали эху
3. Сделали запрос /u/e/echo/-N:1
4. Сообщение есть? Или такое же как в прошлый раз? На 10
5. N = N*2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос /u/e/echo/-N:N
11. Делаем запрос /u/m для всех id из ответа пп.10 которых у нас нет

Это немного упрощает алгоритм и, возможно?, делает ситуацию безопасней, если во время сканирования добавились новые сообщения, но я работаю только с одной эхой. Если такую штуку делать со многими эхами сразу то:
a) понадобятся множественные slice
b) алгоритм станет сложнее, а не проще

Но, конечно, можно брать просто максимальный N для всех эх а потом делать один общий фетч.

1. Выбрали N=16
2. Выбрали набор эх elist: echo.1, echo.2, ... echo.i
3. Сделали запрос /u/e/echo.1...echo.i/-N:1
4. Для каждой эхи в ответе:
- Если сообщение есть или получили тот же id что в прошлый раз, удаляем эху из набора
5. Набор elist пуст? Да! иди на 10
6. N = N * 2
7. N > 1024 ? Если да, бросаем это дело и начинаем полный фетч
8. Перейти на 3
10. Делаем запрос(ы) /u/e/все эхи/-N:N
11. Делаем запрос(ы) /u/m для всех id из ответа пп10

Написал просто, чтобы не забыть.