[>]
Re: я наверное тоже напишу спецификацию
idec.talks
ahamai(blackcat, 2) — ahamai
2024-11-01 23:31:33
Проблемы экономии трафика я не вижу, я каждый раз нажимая F5 в браузере потребляю трафика больше, чем в ii клиенте потратил бы за день. Но для этого всё равно есть list.txt, который можно даже кэшировать. lim только для новоподключившимся к большим эхам. стандарта на годовые эхи не будет, но для себя, если эха разрастётся, то поедет в эха.25 и так далее. это не вопрос спецификации, это вопрос реализации на конкретной станции.
[>]
я наверное тоже напишу спецификацию
idec.talks
ahamai(blackcat, 2) — All
2024-11-01 23:26:26
Текущую проблему (одну из трёх) я вижу в том, что не пишут софта. Сейчас ровно один человек пишет клиент, и он программист. Раньше софт писали любители. Я сам любитель и смотрю с точки зрения любителей
> вообще. я заметил, когда вопрос политики и проектирования уходит к программистам, они решают это с какой-то особой, программисткой точки зрения. поэтому решают вообще не ту проблему: вопрос "ты грепаешь миллион телефонных номеров но семь не подходят под фильтр" меня убил, типа лучше сделать идеальный фильтр, чем за две минуты удалить эти номера вручную, и это единственно верный способ. собственно, этот ответ объясняет вообще всё
и чем проще формат и чем меньше непонятных букв, тем больше может возникнуть желание написать клиент. для принятия решения нужно 100% пунктов, какие ты можешь выполнить. хоть одно непонятное слово может сразу подавить желание заниматься этим. желания спонтанны, но чем больше погружаешься в скуку, тем больше это тебя демотивирует. А просто меняться списками легко и приятно.
И если я решу проблему контента, я сделаю свою спецификацию, чтобы у того, у кого возникло желание писать клиент, было как можно меньше вопросов и желания всё бросить.
Там будут u/ e/ u/e u/m и u/point.
Всё. Будут ещё серверная рекомендация k/v, сейчас там только lim/XXX. это не влияет на написателей клиентов, так как это строчка в конфиге, endpoint в любом случае прописывают при начале работы в сети. это не влияет на писателей серверов, так как они делают базовую реализацию, а потом могут навешивать любые ендпоинты, и просто писать на своей станции "конфиг при подключении к станции такой-то такой-то"
И, думаю, я просто изменю list.txt, который всегда будет выдавать после описания хэш эхи, кто из клиентов-фетчеров захочет этим пользоваться. пусть пользуется, кто не захочет - и не надо.
Вот такая у меня будет спецификация, абсолютно не ломающая совместимость со старым ii. Но это будет только тогда, когда будут контент и юзеры, чтобы были хотя бы потенциальные желающие писать клиент.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — shaos
2024-11-01 23:02:10
речь была о мусоре в /u/e который нужно игнорировать
а какая разница в запросе??? бандл он нужен только для одного, получить информацию. если тебе нужна информация, ты делаешь конкретный запрос. а так, ты сделал некорректный запрос, ну тебе выдался список пустых эх. И ЧТО.
u/e работает только так. даунлинк запрашивает список эх. аплинк выдаёт бандл. всё. тут нет ничего больше, всё взаимодействие u/e именно такое. ничего другого там нет. список эх -> корректный с точки зрения формата бандл. какая разница кто какой запрос делает, на любой запрос u/e делает только одно, выдаёт запрошенный бандл. всё примитивно. как три копейки, ничего другого там просто нет.
валидация урл на инъекции и прочее это вообще не про ii, это задача другого уровня, задача веб-сервера, url и прочее, это применимо к любому запросу к любому серверу. ii же работает абсолютно топорно - вот тебе список эх, вот тебе бандл, ничего другого в принципе там быть не может. на вход может быть подано вообще что угодно, для станции это список эх. станция смотрит, если есть такая эха, выдаёт контент, если нет, выдаёт пустую эху. ничего другого корректная станция выдать не может. и эту станцию ты сам прописываешь в конфиге.
ну блин, очевидные же вещи. протокол настолько примитивен и технология сети настолько примитивна, что как тут могут возникать такие вопросы. запрашивающий ожидает только одно, бандл. ну создал ты левый урл, получил бандл с кривыми эхами, и что? что от этого. у тебя на руках такой бандл. и что ты им сделаешь? а ничего другого ты получить не можешь. опять же вопросы инъекций, это вопросы чуть более низкого уровня, чем ii, и если сервер пропустил инъекцию, это вина не ii.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 22:48:54
кстати, любителям множества запросов могу предложить алгоритм хэширования чанков. весь список эх делится на чанки, например по 64 сообщения, и от каждого чанка берётся хэш. первым запросом проверяется хэш чанков, и берутся только те чанки, которые изменились.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 22:47:26
> На моё сообщение ты как-то очень непрямо ответил.
я ровно в каждом сообщении пишу ровно одно и то же.
1. меня не интересуют стандарты и технологии. как я могу ответить вопрос про стандарты и технологии, если мне это неинтересно, и для меня это вообще не проблема, какой бы стандарт в итоге не приняли.
2. вспомните 2014 год. у меня каждое сообщение ровно про одно - вспомните 2014 год. всё. ни о чём другом я не пишу. и про технологии я пишу только в этом разрезе.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 22:36:39
> У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.
u/e для этого вообще не нужна, достаточно e/
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 22:35:47
> Не вижу смысла минимизировать число запросов.
ну, в 2014 это было проблемой, раз /e заменили на /u/e. а вообще запрос вещь дорогая, это и лишние tcp-фреймы, и лишняя нагрузка на сервер, и лишняя строка в логах :) упаковка в один запрос лучше в любом случае. иначе можно было бы на /m и /e остаться. и мы бы остались, если бы запросы не были столь дорогими, пришлось прикручивать изначально ненужные бандлы. я не знаю, в текущих реалиях можно было бы, если создавать сеть сейчас, остаться на /m и /e - это бы сильно всё упростило :)
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — ahamai
2024-11-01 22:52:07
Речь была вроде не про мусор в выводе /u/e а про мусор в запросе /u/e - такой запрос кто угодно может сделать
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — ahamai
2024-11-01 22:31:30
а, ну ещё проблема в сути вопроса - нахрена, чтобы навредить, давать НЕКОРРЕКТНЫЙ БАНДЛ??? вот тут вообще непонятно. логичнее давать абсолютно корректный бандл, содержащий, например каждый раз тысячу разных msgid с некорректными данными или просто со случайным флудом
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — ahamai
2024-11-01 22:28:41
если тебе дают некорректные данные - ты должен падать - это основа безопасности. как и кому в голову может прийти идея их валидировать
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — revoltech
2024-11-01 22:23:06
> Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают.
ты программист, наверное. а речь про любителей.
> А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.
ты. синкаешься. с доверенным. узлом. всё. а теперь сам перечитай свою же фразу.
ps. при запросе (запросе от тебя) система автоматом разбирается. если есть файлик, то это эха с данными, если всё остальное - то это пустая эха. и ты выдаёшь такой же полностью корректный бандл, где просто перечисляется куча пустых эх. вот тебе вход, список, чего угодно, любой ахинеи. вот тебе выход - ответ на твой запрос, что эха КРАКОЗЯБЛ1 и эха КРАКОЗЯБЛ2 пусты. это полностью корректный и абсолютно формализуемый бандл. бандл состоит только из двух вещей, msgid и эхи, и выдаёт такой бандл, что бы у тебя не запросили вообще.
две стороны. одна даёт список эх, не важно, реальный или абстрактный мусорный. вторая по этому списку выдаёт абсолютно корректный бандл по всем этим эхам, какие бы они не были. всё. не может быть другого варианта, в принципе. список эх -> бандл.
> Или сознательная атака.
то есть, тебя собирается атаковать собственный аплинк. И ТЫ ПРИ ЭТОМ ПЫТАЕШЬСЯ ВАЛИДИРОВАТЬ какие-то данные? ты вообще сам понимаешь, что говоришь - тебе дают заведомо некорректные данные, а ты говоришь "нет, не отлуп давать, а пытаться хоть что-то свалидировать, ВДРУГ ТАМ ЧТО-ТО хорошее?"
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — ahamai
2024-11-01 22:22:24
Я попытался склеить твои сообщения фрагментные в одно и осознать. Но не смог. На моё сообщение ты как-то очень непрямо ответил. По кр. мере я не считаю что ты меня понял и ответил так, чтобы я понял в ответ. Почему уж это происходит так -- я не хочу разбираться. Давай я перестану тогда тебя беспокоить. Буду заниматься дальше своими делами.
[>]
Re: Разбор idec №2
idec.talks
revoltech(spnet, 4) — ahamai
2024-11-01 22:08:57
ahamai> Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?
Дык я и начинаю собирать свою ноду. Слайсы мне в этом вообще не помешают. А ещё у меня там будет автопереключение транспортов — по одному и тому же порту можно будет запрашивать как HTTP, так и Nex/Gopher. И потом ещё после стандартной реализации IDEC будет сбоку приделан совсем несовместимый с ним протокол, ещё более простой и при этом решающий ровно те же задачи, но куда более красиво, компактно и всего пятью эндпоинтами.
ahamai> Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор.
Не в выводе, а на входе. Это существенная разница.
ahamai> Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату.
А ты уверен, что ты сам-то суть понимаешь? Это не про доверенные узлы вообще. Для запроса /u/e пароль не нужен, тебе запрос с дичью вместо эхонеймов может прислать вообще кто угодно, когда угодно и в каком угодно количестве.
ahamai> Единственный вариант, когда там может быть мусор - это СБОЙ.
Или сознательная атака. Если твоя нода при этом будет падать от малейшего чиха, толку от неё мало. У меня вон VPS-ку всякие васяны постоянно по SSH брутить пытаются, судя по логам. И обламываются на корню.
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — shaos
2024-11-01 22:13:20
shaos> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа
Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью. У меня и сейчас опрашивается в одном потоке одна эха и работает все быстро.
[>]
Дракон и Башня
std.game
hugeping(ping,1) — All
2024-11-01 22:11:13
Вы -- дракон. Самый настоящий -- большой, крылатый, летающий и даже способный колдовать.
Уже много столетий, вы живете на Земле. Нет, не среди людей. Грязные и перенаселенные города этих созданий вас не прельщают. К тому же, там вам пришлось бы скрывать вашу истинную сущность.
Только здесь, в созданной вашей магией сети пещер, вы можете быть собой. Это место надежно сокрыто от глаз людей и их искусственных слуг -- радиолокаторов и спутников.
Но сейчас настало время покинуть родное гнездо. Старая карта, хранимая вами испокон веков, готова раскрыть свои секреты своему владельцу, то есть вам!
Дракон и Башня это фентезийная текстовая приключенческая игра.
Игровой процесс традиционный для игр на движке INSTEAD. Вам предстоит исследовать мир, собирать и использовать предметы, общаться с персонажами, решать головоломки и многое другое.
Предупреждение: Игра не предназначена для маленьких экранов и играть в нее на таковых будет неудобно. На планшете играть скорее всего получится достаточно комфортно. Вы можете изменить масштаб текста в настройках игры (шестеренка в игре, или кнопка настройки в главном меню).
https://instead-games.ru/game.php?ID=395
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 21:37:07
По мне проблемы ровно три: отсутствие контента, отсутствие клиентов, отсутствие юзеров. Проблему внезапного лишнего трафика решает элементарное внедрение хэширования эх - оно сокращает трафик, и в отличие от адаптивных и ?sf даёт полную гарантию синхронности эх.
Мне вообще эта движуха напоминает создание очередной левонетки, где на серьёзных щах пишут полиси и прочее, раздают эхи, раздают на них модераторов и комодераторов, прочая движуха, а потом остаются с тремя юзерами (зато все модераторы друг друга). Ну или один год, про который я где-то чё-то говорил.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 21:32:56
но вообще причина не особо понятна. я опрашиваю shaos каждые 5 минут, сейчас слайсами раньше полным фетчем. до h/x и с полным фетчем это 12 мб в сутки (при этом я тяну rss-эхи). после h/x и с полным фетчем 2-4 мб в сутки. (со слайсами, кстати, трафик почему-то нифига не уменьшился). в http есть gzip, который тоже экономит трафик.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 21:29:16
> 2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.
полный фетч периодически необходим. и он решает все вопросы. вопросы "уехал в круиз на полгода" тоже решает полный фетч. а лимиты, как и любой другой k/v, можно легко добавить вообще не ломая совместимость с любой версией ii, просто меняя endpoint (что было заложено изначально, когда схема /z менялась на схему /u)
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — revoltech
2024-11-01 21:22:01
Мне, старому фидошнику, непонятно, зачем фетчить сразу несколько станций. :) лично я качаю только с shaos
[>]
Re: Рома порвался
idec.talks
ahamai(blackcat, 2) — Andrew Lobanov
2024-11-01 21:20:04
> Изменения ради изменений. Ты бы классно вписался в современную IT-индустрию с такими подходами.
я вообще не трогаю технологию. она по мне изначально идеальна. я про внедрение проекта, новых пользователей, новый софт и прочая инфраструктура - ничего этого нет. при Стали^W мне каждую неделю новые клиенты выходили :) была куча юзеров, эх и прочего. сейчас всё глухо, несколько месяцев активность вообще была околонулевая. Даже shaos свой форум в эху не переформатировал. :) Я думаю, если бы жизненные обстоятельства мне не помешали, и сеть и технология сейчас были бы куда популярнее. Сейчас я тоже хочу заняться именно контентом, есть несколько идей, но жизненные обстоятельства сейчас куда хуже, к сожалению. Попробую. Ваши форматы меня не интересуют вообще, idec я прочитал только несколько дней назад, новый не читал.
Я ПРОСТО НАПОМИНАЛ 2014. Делали формат, который ПОЛНОСТЬЮ совместим с ii, но при этом экономит трафик. Итог:
1.
2.
[>]
Re: Рома порвался
idec.talks
ahamai(blackcat, 2) — Andrew Lobanov
2024-11-01 21:10:19
О. Третий. Гы-гы, проблемы проектирования... попытка решить болезни роста прежде чем они возникнут - погубило не одну сотню проектов. ii выжил, и именно благодаря своему проектированию и своему позиционированию. С технологией у текущей сети нет проблем, вообще. Есть проблемы с контентом.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 21:04:21
> Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.
меня не интересует стандарт. ВООБЩЕ. у меня есть /u/e, который проживёт ещё 100 лет и переживёт всех модернизаторов.
я просто напоминал о 2014 году, когда делали стандарт. сейчас 2024 год и опять делают стандарт. на этом всё. умному - достаточно.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 21:02:04
> Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:
Это не проблема. Это основа. Хотел вчера ответить revoltech, но отвечу сразу здесь.
ii это социальная сеть малых сообществ. Так она всегда и называлась. Она не про технологии, она про любительское программирование, радиолюбительство, клуб юного техника и прочие порождения Дворца Пионеров. Чтобы каждый мог собрать свою ноду и общаться со своим хомячком. Потому что это просто. Весь протокол постоянно упрощался. Какие вообще слайсы?
Ещё мне там понравилось, что второй человек уже указывает, что в выводе /u/e может быть мусор. Они походу вообще не понимают сути. Ты синкаешься с доверенным узлом по предельно формализированному и простому формату. Единственный вариант, когда там может быть мусор - это СБОЙ. И как можно в этой ситуации поступать "ну давайте что-нибудь попробуем вычленить". Да ты можешь получить 800 дублей или ещё чего похуже. Вся история и фидо, и ii, говорят об этом.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — hugeping
2024-11-01 20:52:21
> Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...
x/h единственный валидный триггер. он бывает в двух состояниях "эха изменилась" и "эха не изменилась". всё остальное не даёт полных гарантий.
[>]
Re: Разбор idec №2
idec.talks
ahamai(blackcat, 2) — shaos
2024-11-01 20:50:07
> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять
так было в босфор. я ща гляжу на него, прикольная была штука, только клиентов и фетчеров для него не было :)
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — hugeping
2024-11-01 20:29:48
Реверсная выдача это когда клиент качает список в обратном порядке пока не дойдёт до знакомых хешей? Это может работать только для отдельных эх (типа /e но в обратном порядке).
Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа, где будут все эхи вперемешку (по заданному списку) и имя эхи будет в каждой строке, типа:
echo.1:msgid999
echo.2:msgid998
echo.1:msgid997
…
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — shaos
2024-11-01 18:25:30
shaos> Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…
Да не, ерунда это всё. Не могу я, в общем, ничего принципиально иного придумать. Ну, а о реверсной выдачи ID что думаешь?
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — hugeping
2024-11-01 17:46:38
Ну теоретически если кто хранит мессаги в MySQL или SQLite, то время добавления можно и сохранять, а если только в файлах, то по времени создания файла? Можно попробовать - всё равно ведь не всё перебирать надо, а только последние сообщения в эхе пока не найдём «прошлое»…
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — shaos
2024-11-01 15:46:23
Выше по списку в ленте сообщений где сверху показаны последние сообщения, а в списке хешей эхи оно естественно будет ниже по списку...
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — shaos
2024-11-01 15:48:45
shaos> Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).
Я имел в виду время принятия сообщения нодой, а не время создания сообщения, конечно.
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — shaos
2024-11-01 15:48:13
shaos> Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...
Он не то чтобы его заменяет, а решает бОльшую задачу - sync только новых сообщений. При этом /x/h не нужен, так как решена более общая задача. Но хеши надо хранить для всех эх всех нод с которых мы фетчим...
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — hugeping
2024-11-01 15:37:13
Время ненадёжно т.к. сообщения приходят так как приходят из-за особенностей роутинга и последовательности фетчинга, а вовсе не в хронологическом порядке, и старое сообщение вполне может внезапно "всплыть" выше по списку чем более новые ответы на него (см. беседу revoltech с Ромой).
[>]
Re: Разбор idec №2
idec.talks
shaos(spnet, 2) — hugeping
2024-11-01 15:34:13
Если сохранять хеш последнего принятого сообщения для КАЖДОЙ опрашиваемой ноды, то тогда да - имеет право на жизнь. По идее оно может собой заменить хеш списка сообщений для эхи (мой /x/h или /list.txt?h=1) т.к. список не может расти изнутри - только с конца...
[>]
Re: Рома порвался
idec.talks
shaos(spnet, 2) — shaos
2024-11-01 14:35:30
TOP10 VISITORS:
[1] Facebook point=0 web=1027 up=22.9MB (33%)
[2] 176.109.111.x point=46 web=0 up=16.7MB (24%) <--- tavern (2/hr)
[3] 92.63.98.x point=70 web=0 up=5.9MB (8%) <--- tgi (3/hr)
[4] Google point=42 web=480 up=5.7MB (8%) <--- Google (2/hr)
[5] 145.224.100.x point=115 web=1 up=5.0MB (7%) <--- 145.224.100.x (5/hr)
[6] Amazon point=0 web=83 up=4.1MB (5%)
[7] 95.165.9.x point=135 web=2 up=3.3MB (4%) <--- ping (6/hr)
[8] 217.197.116.x point=150 web=0 up=2.7MB (3%) <--- blackcat (6/hr)
[9] 24.130.121.x point=35 web=58 up=2.0MB (2%) <--- spnet (1/hr)
[10] 172.56.42.x point=0 web=35 up=0.2MB (<1%)
TOTAL TRAFFIC: 68MB
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — hugeping
2024-11-01 14:50:13
hugeping> Что думаете?
Продолжаю рассуждать. sf=hash становится надёжной, если только мы после последнего фетча запоминаем hash последнего сообщения которое зафетчили и сохранили. Возможно, о таком режиме Рома и говорил, но я до сих пор воспринимал sf=hash совсем по другому. Так что пишу это, если вы тоже воспринимали это по другому...
Так что sf=hash так же надёжна как и время, если мы после каждого фетча успешного записываем hash последнего взятого сообщения для этой ноды.
Мне, правда, не нравится необходимость хранить эти хеши для фетчей (причём для каждой ноды), поэтому идея с временем нравится больше. Но тем не менее.
[>]
Re: Топ 10 ваших команд
linux.14
shaos(spnet, 2) — Andrew Lobanov
2024-11-01 14:33:54
Оказывается mpv в дебияне есть :)
Description: video player based on MPlayer/mplayer2
mpv is a movie player based on MPlayer and mplayer2. It supports a wide variety of video file formats, audio and video codecs, and subtitle types.
Changes from mplayer2 to mpv include:
* Removal of lots of unneeded code to encourage developer activity
* Better OSD rendering
* Cleaned up terminal output
* Improved OpenGL output
* Encoding functionality (replacement for mencoder)
* Wayland support
* Support for playing URLs of popular streaming sites
* Screenshot improvements
* ...
See mpv(1) for more info regarding changes between MPlayer, mplayer2 and mpv.
Homepage:
https://mpv.io/
[>]
Re: Разбор idec №2
idec.talks
tuple(ping,54) — hugeping
2024-11-01 14:41:38
hugeping> Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)
Стоило прийти в idec, как его уже хоронят :)
[>]
Re: Разбор idec №2
idec.talks
hugeping(ping,1) — hugeping
2024-11-01 14:35:41
Подумал тут ещё... Хочу добавить. Может какой-то мозговой штурм начнётся. Но это все в рамках некоторого "потенциально нового" ii-подобного протокола. idec3 :)
Адаптивный фетч тоже не 100% надёжен. Но ненадёжен по-другому. Речь о той точке алгоритма, когда мы останавливаемся. Когда видим что такое сообщение у нас есть и начинаем фетч. Это лучше чем жёсткий лимит, но всё-ещё не абсолютно надёжно.
Поэтому мне кажется, что в "идеальном" протоколе нужно выбрать что-то принципиально иное.
1) Либо полный sync если хоть что то поменялось (но тогда стоит вернуться и к перекатыванию эх, потому что в этом решении нет масштабировании при бесконечном росте эхи. Короче - это "принятие" ii)
2) Выборка, основанная на времени.
Вроде бы Рома делал такое когда-то, может ошибаюсь. Запрос вида: дай мне сообщения которые пришли с такого-то времени (время - ну пусть секунды эпохи unix в utc).
Да, тогда мы немного завязаны на время, но это вроде бы окончательно решает всё. Или нет?
Что думаете?
[>]
Re: Топ 10 ваших команд
linux.14
shaos(spnet, 2) — tuple
2024-11-01 14:24:59
Из плееров у меня по клику на видос запускается VLC, но он неудобный - тормозной, рюшечек у окошка много и т.д.
А mplayer просто окно без ничего - всё управление горячими клавишами, которые я за 10-15 лет его использования уже выучил :)
Например там можно легко подкорректировать задержку между видео и звуком - у меня есть много старых оцифровок, где оно постепенно уезжает. По кадрам можно идти, видя в консоли смещение в долях секунды и т.д. Для коидирования/перекодирования видосов я использую mencoder и иногда ffmpeg...
[>]
Re: Рома порвался
idec.talks
shaos(spnet, 2) — Andrew Lobanov
2024-11-01 14:02:19
> Ну я Шаоса, вроде, не тяну.
Ну как не тяну? Тянешь, но по старому списку эх 2021 года и по старому адресу…
[>]
Re: Рома порвался
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2024-11-01 11:45:57
AL>> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
hugeping> m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.
Ну m/, по размышлению, мне тоже кажется полезным. Даже просто взять и получить сообщение с помощью curl это удобно. А вот e/ никогда не видел, чтобы использовали. Разве что на заре ещё ii был клиент на баше и dialog, который был онлайн-клиентом и использовал как раз e/ и m/, если мне не изменяет память. Хотя, по факту, разделить строчку и декодировать base64 на баше всё равно просто.
[>]
Re: Рома порвался
idec.talks
hugeping(ping,1) — Andrew Lobanov
2024-11-01 11:11:56
AL> Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
m/ постоянно использую для отладки. Удобно. Про e/ сходу не могу вспомнить.
[>]
Re: Рома порвался
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-11-01 11:02:39
revoltech> Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.
Ну я Шаоса, вроде, не тяну. Если кто-то транзитом протащит, затащу к себе.
revoltech> Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?
Ну... На самом деле, я ещё думаю, что есть смысл выкинуть e/ и m/ :)
[>]
Re: Рома порвался
idec.talks
revoltech(spnet, 4) — Andrew Lobanov
2024-11-01 10:34:14
Я там в revoltech.local (у Шаоса) пофантазировал на тему, как можно было бы весь протокол упростить, не будь необходимости держать обратную совместимость с ii/IDEC. Причём там и файлэхи тоже в общую структуру прекрасно ложились бы, например.
Но сначала актуальный стандарт IDEC реализую в ноде своей, а потом уж посмотрим. Так что там, 40 мессаг на запрос устаканили, больше дополнений к доке не будет, можно приступать к запилу?