> Больше спектрумов, хороших и разных!

Безусловно :)

> Лучше нам завести под это дело отдельную эху, наверное. Я предлагаю общую
> спектрумовскую пока завести, чтобы подходила под любые спектрум-совместимые
> обсуждения :)

Я планирую поднять свой узел IDEC и там создать несколько специализированных эх по темам касающимся Спринтера, а тут действиетльно можно пока общую эху zx.spectrum завести ;)

> Кстати, в IDEC любой поинт может создать эху на уровне своего аплинка.
> Достаточно просто написать в несуществующую конференцию и она создастся
> (по крайней мере в таверне так). А там уже можно кинуть анонс сюда, мы
> прокинем по всей сети её :)

Попробовал послать сообщение в эху zx.spectrum - получил Error: 500 Internal Server Error ;)

Запустил таки ii-php у себя на доменном имени на специально выделенной машине PowerMac G4 400МГц с Debian-линухом на борту, стоящей у меня дома в Пало-Альто, штат Калифорния :)

Пожалуй это будет первый узел ii/idec-сети, расположенной на американском континенте (и возможно первый узел на неинтеловской архитектуре?)

Беру с таверны несколько эх, а также создал заглушки для своих эх ( в частности silicon.valley.local ; )

В будущем планирую на той же машине поднять Gopher-сервер и TNFS-сервер (для компьютеров ZX-Spectrum оснащённых сетевой карточкой Spectranet)

Shaos

Ну и от меня держите :)

{
    "nodename": "shaos",
    "client": " http://shaos.net:8085/ii-point.php?q=/",
    "web": " https://shaos.net:8085/ii-web.php",
    "sysop": "shaos",
    "contacts": {
        "email": "me@shaos.net",
        "phone": "+1xxxxxxxxxx",
        "web": " http://shaos.net"
    },
    "description": "shaos.net IDEC node",
    "uplinks": [
        [
            "tavern",
            "15m"
        ],
    ]
}

Существует 2 пустых сообщения в idec.talks, которые вызывают ошибку при фетче из ii-php:

fetch http://idec.spline-online.ml/u/e/idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum
idec.talks
fetch http://idec.spline-online.ml/u/m/HaYwRbvCz0HDMhN2IrOU/ymc21433dohplAzblytS
invalid message: HaYwRbvCz0HDMhN2IrOU
error saving HaYwRbvCz0HDMhN2IrOU
invalid message: ymc21433dohplAzblytS
error saving ymc21433dohplAzblytS

Наверное если они невалидные их надо в чёрный список, не?

> Добавил в блеклист.

Да - теперь в логах чисто - СПС!

пишу тестовое сообщение

Всем привет

Я познакомился в ii/IDEC только в августе этого года, стал изучать как оно всё устроено и наконец на днях, воспользовавшись открытой реализацией ii-php, поднял свой узел - теперь у меня есть несколько мыслей по возможному будущему этой системы (либо системы, которая может отпочковаться от этой системы, но будет оставаться совместимой со старым IDEC API):

1) Кроме base64 существует чуть более компактный способ представления бинарных данных в виде текста - это алгоритм ascii85, когда каждые 4 байта представляются 5-значным 85-ричным числом, где каждая "цифра" это символ от '!' до 'u', плюс буквы 'z' и 'y' несут особый смысл, кодируя четвёрки нулей и пробелов соответственно - в результате данные раздуваются не в 4/3=1.33 раз, как в случае base64 (или uue), а в 5/4=1.25 раз или меньше, что как минимум на 6% компактнее. Можно немного развить ascii85 для кодирования произвольных бинарных данных, назвав новую систему кодирования скажем ascii85+ задействуя остальные неиспользованные символы: 'x' может кодировать четвёрку 0xFF (это может помочь при кодировании прошивок ПЗУ), 'w' - четвёрку 0x80 (это может помочь при кодировании 8-битных беззнаковых WAV-файлов), 'v' - пока может использоваться для детектирования ошибки, фигурные скобки { и } могут выделять закодированный бинарный блок в тексте (наличие явно заданного стартового символа упрощает парсинг, а наличие явно заданного терминатора поможет обрабатывать пограничные ситуации, когда концовка файла не влезает в 4 байта целиком), а ~ и | могут использоваться для каких-то особых случаев (см.ниже). Этот подход можно использовать для встраивания бинарных файлов в текст сообщений как вложений (аля ююки), указывая имя файла после втавки (чтобы клиент знал с чем этот файл надо есть и надо ли):

Посмотрите на эту весёлую картинку:
{Abhdhj!$^390+-
 ...
 Bhdbdfjg}=funny.gif

Старые клиенты будут показывать такие сообщения как текст, а новые клиенты могут получать такие сообщения даже со старых узлов и показывать картинки как картинки или файлы как вложения (ряд иконок внизу сообщения), которые можно сохранить на диск на стороне клиента.

2) Этот же ascii85+ можно использовать для уменьшения размеров бандлов на 6% сделав новый вызов в API - например /u/n/msgid/msgid/msgid... (вместо /u/m/... который может остаться для старых клиентов) - и результат работы этого вызова может выглядеть примерно так:

msgid:{!"#$%&'()*+,-...}
msgid:{0123456789...}
msgid:{ABcded...}

где в фигурных скобках будет ascii85+ сообщений (этот алгоритм не является url-safe, поэтому в других местах API где надо url-safe останется всё тот же base64url).

3) Идея, что msgid является хэшом сообщения, с моей точки зрения является в ii ключевой, поэтому редактировать сообщения, сохранённые узлом (а тем более переданные на другие узлы) ни в коем случае нельзя! Ведь это поменяет контент и хэш уже не будет совпадать! Если же контент константен, то всегда можно восстановить msgid по самому сообщению, если вдруг msgid оказался утерян. Кроме того на стороне клиента (либо другого узла после фетча) можно проверить целостность сообщения, посчитав его хэш и сверив с msgid - если оно не совпадает, то либо это старое сообщение (отредактированное на узле, где это можно было делать, или посчитанное в стародавние времена, когда хэши в ii считались иначе), либо подменённое или испорченное новое сообщение - можно просто подсветить такое сообщение особым образом на клиенте и читатель сам будет решать, что ему с таким сообщением делать.

4) Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения - например сервер принимая от клиента текстовое сообщения классического вида добавит в его список тэгов новый тэг trick/0 и посчитает хэш сообщения - елси хэш не начинается скажем с символа '0', то алгоритм инкрементирует значение в этом тэге (trick/1) и считает хэш ешё раз - если опять не стартует с '0', то инкрементируем ещё раз и т.д. пока хэш не станет начинаться с нуля (в среднем на подготовку "красивого" msgid должно уходить порядка 32 вычислений хэша - иногда меньше, иногда больше) - в этом случае все узлы точно будут знать, что все "новые" сообщения с msgid вида 0... являются новыми "обычными" сообщениями (чтобы отличить от старых сообщений с именами случайно начинающимися с 0 можно проверить наличие тэга trick в заголовке сообщения - если он есть, то это новый тип сообщения с возможными вложенными файлами). Если каждая точка системы точно знает, что это новое сообщение, то она также может проверить целостность сообщения пересчитав его хэш и сверив с msgid ( ведь новый стандарт должен будет явно запретить редактирование или подмену сообщения уже сохранённого узлом ; ). Старые узлы и клиенты будут передавать такие сообщения как самые обычные (если не запнутся на неизвестном тэге trick).

5) Тип сообщения 1... может обозначать закодированный бинарный файл, когда в теле сообщения нет текста, а сразу идёт блок ascii85+ {...}. При посылке такого сообщения отправляющий клиент может задать новое ключевое слово @crc32:0xFFFFFFFF для указания контрольной суммы, которая при сохранении сообщения будет вставлена узлом в строку тэгов в виде .../crc32/0xFFFFFFFF и которую принимающий клиент может проверить после восстановления файла. Размер такого сообщения по понятным причинам будет ограничен - может быть даже придётся уменьшить текущий лимит 87кб до 32кб, чтобы эта реализация была совместима с ограниченными размерами памяти недокомпьютеров, которые могли бы участвовать в работе сети - в этом случае размер самого большого бинарного файла, который можно таким способом отправить, будет составлять порядка 26кб. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые.

6) Тип сообщения 2... может обозначать составной объект, когда ранее отправленные сообщения типа 1... на самом деле являются кирпичиками, из которых строится большое сообщение. В теле такого сообщения могут перечисляться как блоки {}, так и ссылки на внешние сообщения типа 1:

~1gjkwui4iuwqrezD56az
~1ui4iuwqrezD56azFejs
~{......}|это вставка блоба ascii85+ (комментарий после | до конца строки)
~1uwqrzFejsDSGFeekjkd|это ссылка на другой объект, который должен быть вставлен при сборке
{....}=666.bin|это объявление именованного блоба (без вставки)
~666.bin
~666.bin
~666.bin|это вставка копии именованного блоба (всего 3 копии подряд)

в примере выше показано как можно повторять несколько раз бинарный кусок, объявленный в том же сообщении (666.bin). Такой тип бинарного сообщения снимает любые ограничения на размер передаваемого объекта, который перед передачей может быть порублен на кусочки. При отправке такого сообщения также может быть использовано ключевое слово @crc32, которое как и в предыдущем случае будет вставлено узлом в строку тэгов при сохранении. Старые узлы и клиенты будут показывать такие сообщения как обычные текстовые (как в примере выше). В случае реализации сообщений 1 и 2 типов на уровне сети для передачи бинарных данных отпадёт необходимость в поддержке файлэх, которые выглядят несколько неестественно применительно к ii (например они не приспособлены для пересылки через последовательные каналы передачи данных, в то время как все остальные подсистемы IDEC представлены в текстовом виде и могут быть использованы через интерфейс терминала).

7) В будущем при отправке сообщения от поинта узлу к ключевым словам можно будет добавить ещё и подпись @sign:0xFF...FF по алгоритму скажем HMAC-RIPEMD-160-96 (с одним секретным ключом известным отправляющей и принимающей стороне), если достаточно удостовериться в валидности посланного от поинта на свой узел (узел должен знать секретный ключ поинта - точно также как сейчас он знает пароль) и далее при сохранении сообщения на узле (после проверки валидности) такую подпись можно опустить, либо (в будущем) по алгоритму Ed25519 (с публичным и секретным ключами), если требуется проверка достоверности сообщения в пределах всей сети на любом узле и любом клиенте (это более тяжёлая реализация, которая требует наличия двух алгоритмов SHA512 и Curve25519, а также способов передачи публичных ключей всех активных участников сети на все вовлечённые узлы) - в этом случае sign/0x... переедет в строку тэгов для проверки достоверности послания в любой точке сети (и также для проверки целостности данных вместо CRC32), а старые узлы и клиенты просто будут игнорировать этот тэг, как неизвестный.

8) Когда сеть разрастётся, возможно придётся отказаться от хранения всех сообщений на каждом узле (в идеале - когда все фетчат всех) - узлы могут быть разбиты на группы (с избыточностью) для хранения разных наборов объектов (скажем в зависимости от значений 2го и 3го символа в msgid). Существуют разнообразные алгоритмы распределённых хэшей, которые можно применить в данном случае для поиска объектов по хэшу (msgid) на сети ненадёжных узлов. В этом случае сеть можно будет использовать как распределённое хранилище подписанных объектов, которые можно будет задействовать при построении распределённых сайтов, мультиплеерных игр, криптовалют и т.д. Для старых узлов можно предусмотреть механизм, когда они подписываются на специальные скрытые эхи, в которые будут транслироваться копии объектов по группам - в этом случае эти узлы будут продолжать работать в старой парадигме IDEC, но в то же время они будут полезными в рамках новой распределённой сети объектов, раздавая сохранённые на них объекты при необходимости по запросу.

Shaos

> Предложения весьма занимательные, но с моей точки зрения теряется главное примущество idec - дубовость.

Ну с годами idec уже не такой дубовый стал и совсем не маленький, как у вас тут принято считать ;)

> Есть ли смысл в осмысленных msgid, если мы всегда практически бесплатно можем прочитать теги?

Не бесплатно. Чтобы посмотреть тэги, надо найти и прочитать сообщение. Если оно одно, то может и не долго, а если в списке их тысячи?. А так мы по списку можем видеть что есть что (ну разве что с вероятностью 1/64 это может быть "false positive", пришедший от старых нод или взятый из старых архивов, у которого случайно msgid начинается с 0).

> Касательно рассуждений о хэше для сообщений, пришла мысль, что IDEC
> это практически контентно-адресуемая сеть...

Ну по сути так оно и есть :)

> ...и можно как-то прикрутить её к IPFS (или наоборот) для хранения сообщений

А зачем прикручивать, если IDEC по сути вполне годится на роль "downsized IPFS"? ;)
Самая первая версия IPFS v0.1 появилась в феврале 2015, а самая первая версия ii v0.1 - в марте 2014. Получается IPFS это "upsized ii" :)
А так внутри IPFS есть "Distrubuted Hash Map", который есть последний пункт моих мыслей применительно к IDEC :)
И как над IPFS появилась криптовалюта Filecoin, над IDEC может в перспективе появится IDECoin и всё забурлит и запенится ;)
Шутка...

>> Хэш msgid может быть не визуально рандомным как сейчас, а будет способным нести информацию о типе (или о версии) сообщения
> Мне кажется такую функциональность проще реализовать в виде варианта запроса
> индекса, который будет возвращать (кроме идентификатора и закодированного
> сообщения) строку с тегами, либо отдельным суффиксом у ID. Правда, хранение
> метаданных в ссылке напоминает костыль в gopher, когда префикс в URL определяет
> то, как клиент будет отображать полученное содержимое.

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

Несколько комментариев к моему изначальному сообщению.

- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в ii-php и iing (и скорее всего в старом ii, судя по статистике использования символов в хэшах архивных сообщений), чтобы недвусмысленно было написано, что 2 небуквоциферных символа в base64 надо заменять на A (большую) и z (маленькую), а то сейчас в документации написано "for example A and Z" и новые реализации пытаются следовать документации, получая несовместимые решения (ii-go).

- При поддержке вложений в новоявленном формате ascii85+ чтобы отличить их скажем от исходника на языке Си или JSON-а в начале сообщения можно добавить ключевое слово @attach за которым будет идти число включений и сервер будет убирать это в строку тэгов сохранённого сообщения например .../attach/3 будет означать, что по ходу сообщения должно встретиться 3 вложения в формате ascii85+ (правда это означает, что в этом же сообщении не может встретится кусочек программы на C/C++/Java или JSON, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

> Реализация всё ещё пишется за несколько часов :)

Это далеко не так ;)

> Да и не повод дальше усложнять.

Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

Ну для начала - добавляет бинарных данных в рассылки.

> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.

Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

> А найти и прочитать сообщение в общем случае это O(1).

Скорее O(n)...

> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.

Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

> Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

и это тоже можно сделать ;)

ну или по классике - в теле письма писать URL на ii-объект:

ii://1KpcmGrc9pUtZQ6Puv1z

По поводу общих поинтов - PGP/GPG тяжеловат потому как многообразен - надо что-то одно широко известное выбрать и поддержать, но только цифровую подпись - без шифрования (которое в IDEC по-моему противопоказано), например можно взять отданный в общенародное достояние алгоритм Ed25519, существующий уже 10 лет и не подпадающий ни под какие патенты - в нём есть 32-байтовый публичный ключ и 64-байтовый секретный ключ (половина из которого это копия публичного ключа). Публичные ключи распространяются по всем узлам и клиентам (например посредством специальной эхо-конференции от имени пользователя как поинта своего узла) и идентифицируют глобальных пользователей (которые всё также могут оставаться поинтами на своих узлах). К сообщению подписанному цифровой подписью Ed25519 цепляется 64-байтовя signature (в строке тэгов после тэга signature/ например как 128-символьная шестнадцатиричная строка либо как 103-символьная строка в кодировке BASE32 либо как 86-символьная строка в кодировке BASE64URL, либо как 80-символьная строка в кодировке ASCII85 где символ / подменён скажем на | - хотя наверное надо таки использовать BASE64URL как родной способ кодирования бинарных данных в IDEC). Чтобы проверить валидность сообщения, по имени пользователя (msgfrom) берётся его публичный ключ (предварительно распространённый) и по телу сообщения проверяется его цифровая подпись, чтобы удостовериться, что письмо не подменено или не подписано поддельным ключом.

Подробнее про внедрения Ed25519: https://ianix.com/pub/ed25519-deployment.html

P.S. Правда надо ещё придумать процедуру восстановления identity если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).

base32 это большие буквы и некоторые цифры - уж лучше обычный hex тогда

а так вроде всё логично :)

И всё-таки, зачем кому-то в прошлом захотелось усложнить ii? ;)

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

Это самая правильная позиция :)

Главное не ломать совместимость со старыми версиями нодов/клиентов

> ii подмножество idec. Если речь про ii, то всё-ещё так. :)

ii более несуществует - есть только idec ;)

и он чуть более сложный...

А кстати небыло мыслей сделать специальный вызов в API, который возвращал бы uplinks?
Типа /fetches.txt

http://idec.spline-online.ml/;idec.talks/linux.14/lor-opennet.17/develop.16/plan.9/zx.spectrum;15
https://.....;something.something;60

Ну и было бы неплохо иметь возможность через API спросить у нода как он называется, а то я сейчас не вижу как по http://idec.spline-online.ml понять, что это tavern

И после этого можно будет строить топологию сети автоматически :)

Всех обитателей IDEC сети поздравляю с Новым 2022-м Годом! Желаю IDEC в новом году разростись до немыслимых размеров и подмять под себя ну скажем всех Спринтеристов (и даже частично Синклеристов), а если получится, то и ещё кого-нибудь в придачу ;)

> Ну если начинать наворачивать вебинтерфейс, то да. Но чисто обмен и хранение пишется часа за 4 +-. По крайней мере на ЯВУ :)

Там мелочей всяких больше, чем на 4 часа, ну да ладно - не суть...

> Какие проблемы решает добавление бинарных данных в рассылки? :)

Ну сообщение становится самодостаточным (если приаттаченные файлы маленькие и влезают вместе с текстом сообщения в лимит)

> А есть такая необходимость? Ведь есть файлэхи :)

Не все узлы подписаны на все файлэхи и глобального поиска по идентификатору нет ;)

> А надо фильтровать?

Ну если будут сообщения разного типа, то да

У меня чото ни с сабжем, ни с idec.spline-online.ml связи нету :(
В живых вижу только 3 узла IDEC (ну кроме моего):
https://dynamic.lessmore.pw
https://club.hugeping.ru
https://tgistation.ru

на lessmore и ping каким-то чудом появляются мои сообщения отправленные с моего узла shaos :)

получается кто-то кроме spline-online.ml фетчит http://shaos.net:8085/ii-point.php?q=/

либо tavern сейчас живёт по другому адресу и продолжает меня фетчить и раздавать другим?...

Спешу сообщить, что мой заокеанский узел IDEC всё ещё существует!

Сегодня я добавил второй путь забирания эх через lessmore т.к. существующий адрес tavern не работает как минимум с 14 июля 2022 года (если пойти туда через браузер, то оно редиректит на какие-то списки ссылок). Несмотря на то, что старый адрес tavern не работает, он как будто-то бы продолжает забирать у меня сообщения по старому списку (я сегодня добавил у себя эху idec.test и её в том списке нет). Во всяком случае всё, написанное мной в idec.talks ушло в сеть и появилось как минимум на узлах lessmore и ping.

Список эх, которые я забираю извне:

	["idec.talks", "Сеть IDEC, её работоспособность и софт"],
	["idec.test", "Тестовые сообщения"],
	["lor-opennet.17", "RSS с сайтов linux.org.ru, opennet.ru"],
	["develop.16", "Программирование"],
	["linux.14", "Эха для линуксоидов"],
	["plan.9", "ОС Plan 9"],
	["zx.spectrum", "Speccy и совместимые компьютеры"],

Список локальных эх:

	["z80.coding", "Программирование процессора Z80"],
	["580.vm80a", "Программирование процессора КР580ВМ80А (i8080)"],
	["nedopc.1801", "Обсуждение компьютера nedoPC-1801"],
	["pdp.11", "Обсуждение архитектуры PDP-11 и совместимых машин"],
	["robby.lang", "Программирование на языке Robby"],
	["balanced.ternary", "Обсуждение троичной уравновешенной системы счисления"],
	["english.talks", "Speak English"],
	["silicon.valley.local", "Локальная конференция Кремниевой Долины"],
	["sprinter.computer", "Общие обсуждения компьютера Sprinter"],
	["sprinter.software", "Обсуждение программного обеспечения компьютера Sprinter"],
	["sprinter.hardware", "Обсуждение аппаратного обеспечения компьютера Sprinter"],
	["sprinternet.io", "Обсуждение сети для компьютера Sprinter"],
	["circuits.cc", "Эха про сайт circuits.cc"],
	["nedopc.org", "Эха про сайт nedopc.org"],
	["shaos.net", "Эха про сайт shaos.net"]

Короткий линк веб-интерфейса моего узла: http://idec.shaos.net

Могу взять благоразумных пойнтов - пишите на me@shaos.net ;)

Shaos

Сегодня подключил забирание с tgistation.ru эх idec.talks и zx.spectrum

> Я просрал домен, как всегда. Так что таверна живёт сейчас по адресу idec.spline-online.tk :)

Привет - всё понятно теперь :)
Поправил настройки у себя, чтобы забирало по правильному адресу

Проверил уменьшение окна браузера - прямоугольник с текстом масштабируется в соответствии с размером окошка и это очень хорошо! Значит будет работать в моём недобраузере на ретрокомпах без глюков (единственный глюк это убегание линейки минусов за пределы рамки, если окно браузера становится слишком узким) - можно заменить на тэг <hr>? Он должен работать в текстовых браузерах тоже :)

P.S. Feed показывает лишь 10 последних сообщений и листать никак - можно исправить? ;)

P.P.S. И содержимое эх не посмотреть - раньше вроде можно было не?

P.P.P.S. Надо настроить забирание bot.habr.rss себе :)

Настроил :)

http://shaos.net:8085/ii-web.php?echo=bot.habr.rss

https://idec.spline-online.tk/ опять помер - говорит EMPTY...

С уже наступившим Новым Годом всех !!!

Debian Etch это извините на минуточку ОООЧЕНЬ старый дебиян :)

https://www.debian.org/releases/etch/index.ru.html

> Debian GNU/Linux 4.0r9 был выпущен 22 Мая 2010. Debian 4.0 изначально был выпущен 08 Апреля 2007.
> ...
> Предоставление обновлений безопасности было прекращено в конце февраля 2010 года.

Боюсь, что его у вас всяческие трояны, черви и вирусы пронизали вдоль и поперёк...

Приветствую

> О, Господи! Так и Plan 9 тогда пользоваться тоже нельзя? Там про обновления безопасности никто сроду ничего не слыхал.

Ну новых планов не выпускают, а дебианы - выпускают. Какой смысл сидеть на старой версии если уже было выпущено много новых с обновлениями (в том числе секьюрными) и т.д.? Вот у меня есть старый повербук на G4 - там ничего новее MacOS X 10.4 не идёт ну я там и сижу в сафари который не обновлялся с 2007 года и тоже страдаю по недоступности многих сайтов https (хотя вот например некоторые летсэнкрипнутые сайты там открываются), но если есть стандартный ПЦ (страше 486), то что мешает поставить дебиян поновее? Религия? ;)

> Да и ретрокомпьютинг - тоже. Как там насчёт эмуляторов C64 или амиги? Или калькуляторы TI? Тут прямо рядом эха со старым железом.

Ретро это хорошо, но старый дебиан - это не ретро, а скорее дырявое корыто ;)

> с 2019 года они интел 32-бит больше не поддерживают, от слова "совсем".

Мимо - Debian 10 "buster" всё ещё поддерживает 32-битный интел и последнее обновление 10.13 вышло в сентябре 2022:

https://www.debian.org/releases/buster/

> Рома опять забил на свою революцию.

Это был тот самый Рома, который и придумал ii ???

Всем привет кто ещё тут!
Какое-то время назад в эхе idec.talks прилетело ко мне сообщение не в тему (причём со старой датой):
http://shaos.net:8085/IDEC-dup.png
А сегодня я обнаружил, что хэш этого сообщения упоминается в двух эхах:
idec.talks:v2gj6Qx0JJmoNlcjcJlg
lor-opennet.17:v2gj6Qx0JJmoNlcjcJlg
Получается в idec.talks пришло сообщение, которое по хэшу совпало со старым сообщением от сентября 2019 года в lor-opennet.17?

Shaos

Привет

Пытаюсь добавить к себе новую эху
Чо опять случилось с твоим серваком idec.spline-online.ru?
Cнова переехал на новый домен?...

Shaos

P.S. Кто такой Виктор и почему он ушёл из сети?

Мой Powermac G4, где с декабря 2021 года крутилась эта нода, приказал долго жить (точнее его старенький ATA-винчестер издох), поэтому перезапустил ноду на обычном PC с AMD64 процом и дебияном на борту...

Уррра - idec.spline-online.ru снова заработал :)

Похоже от этого же сообщения также поплохело эхе lor-opennet.17 на Таверне:

http://idec.spline-online.ru/v2gj6Qx0JJmoNlcjcJlg

Она как бы застряла на нём как на последнем, однако оно вовсе даже старое...

> Какую? Мне бы тоже прокинуть :)

Да ту же самую, что ты в первом сообщении этого треда озвучил - lor.opennet :)

Теперь забирается!

> vit01. Один из старожилов сети и в прошлом крупнейший узел сети.

А - т.е. автор PHP-сервера ii, на котором я сижу? Понятно...

Да ты вроде и так был подцеплен и всё ещё забираешь сообщения ( иначе как бы я с тобой тут общался? ; )

Список эх на ноде я чуток причесал - большинство моих собственных эх всё также пустые, но мало ли, вдруг кому интересно будет ( ниже копия текущего list.txt взятого по адресу http://shaos.net:8085/ii-point.php?q=/list.txt ):

idec.talks:1112:Сеть IDEC, её работоспособность и софт
idec.test:67:Тестовые сообщения
bot.habr.rss:2833:Интересное с хабра. DIY, микронтроллеры, Raspberry PI и пр.
lor.opennet:933:RSS с сайтов linux.org.ru, opennet.ru (NEW)
lor-opennet.17:14259:RSS с сайтов linux.org.ru, opennet.ru
develop.16:438:Программирование
linux.14:915:Эха для линуксоидов
plan.9:18:ОС Plan 9
haiku.os:0:ОС Haiku(R)
zx.spectrum:28:Speccy и совместимые компьютеры
z80.coding:0:Программирование процессора Z80
580.vm80a:1:Программирование процессора КР580ВМ80А (i8080)
nedopc.1801:0:Обсуждение компьютера nedoPC-1801
pdp.11:0:Обсуждение архитектуры PDP-11 и совместимых машин
robby.lang:0:Программирование на языке Robby
balanced.ternary:0:Обсуждение троичной уравновешенной системы счисления
english.talks:0:Speak English
silicon.valley.local:4:Локальная конференция Кремниевой Долины
soviet.computers:0:Обсуждение советских компьютеров
sprinter.computer:0:Обсуждения компьютера Sprinter
sprinternet.io:0:Обсуждение сети для компьютера Sprinter
circuits.cc:0:Эха про сайт circuits.cc
nedopc.org:1:Эха про сайт nedopc.org
shaos.net:0:Эха про сайт shaos.net

P.S. Эху bot.habr.rss я беру c tgistation.ru

Наверное текущие хэши всё также ок - просто надо чтобы IDEC сервера (и наверное клиенты) были готовы к возмжным коллизиям - а то сейчас получилось, что новое сообщение пропало, а на его месте в idec.talks показывается старое сообщение из lor-opennet.17 с тем же кодом - по идее надо в idec.talks показывать новое сообщение, а запись о старом c тем же кодом в lor-opennet.17 по хорошему наверное надо бы удалить, заслав куда-то системный алерт о коллизии с подробным описанием того что куда добавилось и что откуда удалилось - вобщем как-то так...

А что случилось с сабжем?
Difrex тоже ушёл из сети?…

Ещё стянул себе эху oldpc.51t.ru c club.hugeping.ru

Эха хоть и старая (и давно не обновляется), но там много полезной инфы как мне кажется...

Кстати, если кто ещё общается с vit01 можно уточнить у него лицензию ii-php?
А то https://github.com/idec-net/ii-php/ не содержит файла LICENSE :(
Я себе эту репу пару-тройку лет назад форкнул (после нового mysql, но до экспериментов с postgresql) и хочу развивать, но непонятен легальный статус сего кода...

Уточнение: "развивать" под другим названием, чтобы никого не путать:

https://gitlab.com/shaos/iii-php

Пока вот готовлю накатить свои изменения по переводу интерфейса на английский язык ( как у меня на http://idec.shaos.net )

P.S. iii это типа кодовое наименование моего виденья развития сети озвученного в декабре 2021 года:

ii://xDT61Ukip7E064VjCjt4

iii читается как "айяйяй" :)

потом ещё можно и клиента графического написать под названием iii-nizya ;)

> Стукнулся Виктору. Теперь лицензия есть :)

MIT? Отлично! :)

А почему вот эта эха отовсюду выпилена? Питон нынче не в моде? ;)

python.15 44 Python и разные проекты на нём

Я через веб-интерфейс хожу - чаще через свою ноду, реже через другие ( у меня на айфоне постоянно открыты 2 закладки - моей ноды и таверны, которая частенько лежит ; )

Клиентов я всех поглядел когда 3 года назад меня сюда позвали, но ни один не понравился - всё думаю написать клиента своей мечты под iOS и macOS (с возможностью сборки под GNUstep для линуха).

Интересная идея кстати добавить рассылку е-мейл нотификаций в веб-ноде, чтобы предупреждать о внезапной активности в выбранных эхах…