RSS
# Trace: Birds
std.hugeping.micro
hugeping(ping,1) — All
2022-05-20 13:36:36


У меня одна из любимых групп: Procol Harum. И вот, вчера нашёл ещё музыку, которая действует на меня просто каким-то волшебным образом! Понимаю, что о вкусах не спорят, но если вдруг, то вот:

https://www.youtube.com/watch?v=4EvoqLw_QB4&list=PLUnxGWZ-jLPYtcGYwon2PQa1N9q_GpOa0&index=38

Удалось при помощи true-grue найти все 3 альбома. Слушаю непрерывно второй день, никогда не думал, что может так действовать. В чём тут секрет?

# Re: Фильмы о войне
std.hugeping.micro
vvs(ping,12) — hugeping
2022-05-13 15:38:03


hugeping> Пересмотрел в очередной раз "В бой идут одни старики". Очень люблю этот фильм. Кажется, что каждый кадр в нём -- живой.

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

У меня же все старые фильмы всегда вызывают печаль. Многих актёров уже нет в живых :(

Есть и противоречивые ощущения. Хорошо это или плохо, что чёрно-белый фильм кто-то раскрасил? С другой стороны, ведь Быков хотел снять именно цветной фильм, но просто плёнки не хватило.

P.S. Недавно встретил редкий дисклеймер: "данное видео не может служить учебником, а отражает только личное мнение его автора". Сразу задумался о том, какие же ужасные нравы в наше время, если в интернете сплошь и рядом можно наткнуться на агрессивных и нетерпимых людей, абсолютно убеждённых, что именно без них и солнце не встанет :(

# Фильмы о войне
std.hugeping.micro
hugeping(ping,1) — All
2022-05-12 21:40:12


Пересмотрел в очередной раз "В бой идут одни старики". Очень люблю этот фильм. Кажется, что каждый кадр в нём -- живой. По TV в это время шёл "Девятаев". Ну, думаю, дай посмотрю на современное кино... В общем, не выдержал и 20 минут. Задумался. Конечно, нельзя обобщать. Это с одной стороны. А с другой ну, действительно, есть какая-то нехорошая тенденция. Если воздушные бои - то компьютерная игра. (Кстати, наверное самые классные воздушные бои в кино я видел в "Голубом Максе" 1966 года.) Если герои -- то всегда с какой-то постмодернистской стыдливостью... Это в лучшем случае.

А потом, пока искал что-то из современного, натолкнулся на:

https://litvyakfilm.ru/

"28 панфиловцев" помните? В общем, ребята продолжают своё дело и снимают следующий свой фильм. Очень рад за них! Оказывается, мечты иногда сбываются. Только для этого надо много работать. :)

# Re: тест
pipe.2032
oldpc(ping,11) — hugeping
2022-05-06 15:57:00


> Справа вверху login. Если не помнишь пароль, его можно восстановить вроде бы: https://club.hugeping.ru/reset

А откуда у меня пароль, у меня только authstr? Помнится, у меня можно было просто в поле пароля, даже без логина, запихнуть, и всё равно пускало :)

Ладно, iitxt спасёт :)

# Re: тест
pipe.2032
hugeping(ping,1) — oldpc
2022-05-05 18:23:50


oldpc> О, работает. А на сайте как залогиниться? :)

Справа вверху login. Если не помнишь пароль, его можно восстановить вроде бы: https://club.hugeping.ru/reset

oldpc> И почему-то не совпадают записи в блоге в gemini и на веб-сайте.

Вообще, должны. https://hugeping.ru должен совпадать в целом с gemini://hugeping.ru

oldpc> (это тест ответа на сообщение, пишу из горящего ii-txt)

Passed!

# ii-txt-0.9.tar.gz
idec.talks
oldpc(ping,11) — All
2022-05-04 17:34:51


Текстовый клиент, который не так давно отметил своё восьмилетие (первый из существующих клиентов) обновился до версии 0.9

* поддержка загрузки некоторых эх с других станций
* нумерация файлов в каталоге 0001.txt вместо 1.txt

Размер архива вырос на 55 байт :( и теперь составляет 3911 байт. Поддерживается python от 2.4 до 2.7.
(разные версии тестировались на первом пентиуме с Debian Sarge, Etch, и OpenBSD 4.2, 5.0 и др.)
(это сообщение создаётся на третьем пентиуме, правда с новейшей OpenBSD 7.1)

ii-txt-0.9.tar.gz

# Re: тест
pipe.2032
oldpc(ping,11) — oldpc
2022-05-04 12:45:22


О, работает. А на сайте как залогиниться? :)

И почему-то не совпадают записи в блоге в gemini и на веб-сайте.

(это тест ответа на сообщение, пишу из горящего ii-txt)

# тест
pipe.2032
oldpc(ping,11) — All
2022-05-04 12:42:31


тест

# Re: Игровая индустрия: за пределами алгоритмов
std.hugeping
vvs(ping,12) — Peter
2022-05-02 12:12:38


Peter> Понимаю. Я поэтому и завёл "блог", так как часто стараюсь не писать своё мнение, которое может задеть кого-то. А тут вроде - ну субъективное, автор так видит и всё такое. У меня своеобразное восприятие.

Вот про восприятие можно ещё добавить. КМК сводить игру к какому-то единственному аспекту не совсем верно. Только что столкнулся с подобным фактом. Я иногда с удовольствием гоняю в Сокобан. Помнится еще в начале 90-х я впервые познакомился с этой игрой в реализации от Spectrum Holobyte для PC. Однако я был весьма озадачен, когда на 42 (кажется?) уровне я не нашёл решение. После долгих мытарств я пришёл к убеждению, что там содержится ошибка. И хотя в игру включён редактор уровней, но он не позволяет исправлять стандартные уровни, поэтому пришлось лезть туда бинарным редактором.

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

А сегодня встретил реализацию Сокобана для языков с зависимыми типами. Поскольку эти языки предназначались прежде всего для доказательства правильности программ, то графика и эффекты там минимальные :) Но! Зато там есть возможность проверить уровень на наличие или отсутствие тупиков! И это, по-моему, круто. Что демонстрирует, что не атмосферой единой. Ну я так думаю, такое восприятие ;)

P.S. Ссылки:
https://github.com/coq-community/coqoban
https://github.com/mirefek/sokoban.lean

# Re: Сказки про INSTEAD: как всё начиналось
std.club
vvs(ping,12) — hugeping
2022-05-01 14:13:30


hugeping> Мне (как программисту) кажется, что логику проще описывать с помощью обычного ЯП.

Хе-хе. За эту ересь тебе с удовольствием устроили бы аутодафе любители функционального и логического программирования. Ну разве не проще логику описывать с помощью исчисления высказываний или функций? :))

Inform 7 - вполне обычный язык программирования, только не императивный, а реляционный/логический, наподобие Пролога. Единственная его особенность - это синтаксис, напоминающий естественный язык, например английский. Что особенно нравится гуманитариям.

# Re: Сказки про INSTEAD: как всё начиналось
std.club
hugeping(ping,1) — vvs
2022-05-01 09:56:02


vvs> Не знаю, заметил ли это здесь кто-нибудь ещё...
vvs> Inform 10.1.0-beta: https://github.com/ganelson/inform

Да, тоже заметил. Правда, теперь я уже вряд-ли буду заниматься ещё одним проектом. Тут и на МП то времени нет... Русификация Информ7 интересная задача. Но лично для меня, не очень актуальная. Мне (как программисту) кажется, что логику проще описывать с помощью обычного ЯП.

# Re: Сказки про INSTEAD: как всё начиналось
std.club
vvs(ping,12) — hugeping
2022-04-29 19:32:06


hugeping> Русский Inform был отложен.

Не знаю, заметил ли это здесь кто-нибудь ещё, но вчера свершилось то, что Грэм Нельсон обещал уже несколько лет подряд: Inform сменил лицензию на OSS. Кроме того там много нового, например возможность компиляции в C. И, конечно, вопрос перевода Inform7 на русский язык остаётся открытым :)

Inform 10.1.0-beta: https://github.com/ganelson/inform

# Re: Христос Воскресе!
std.hugeping
vvs(ping,12) — hugeping
2022-04-24 14:13:49


hugeping> Христос Воскресе!

Воистину.

Всех с праздником.

P.S. Я конечно агностик и поэтому воспринимаю всё несколько иначе. Но когда-то и для кого-то любой праздник был и остаётся личным. А для остальных - это, прежде всего, традиция и общее культурное наследие. Мы ведь отмечаем не только свой личный день рождения, но и своих близких тоже :)

# Христос Воскресе!
std.hugeping
hugeping(ping,1) — All
2022-04-24 09:03:53


Думал написать в духе текущих событий, что Пасха в тяжёлое время и так далее... Потом подумал, что ведь это всегда так было. Просто у человека есть естественный "предохранитель" -- замечать только то, что в зоне непосредственного восприятия. Даже когда на небе светит солнышко, а вокруг птички да цветы -- смерть никуда не делась. Зло никуда не делось. Где-то идёт очередная война. Кто-то кричит от страха и боли. Кто-то умирает. Легко рассуждать "о высоком", когда ты сидишь в тепле, с кружкой чая в руках...

Это -- не нормально. Мир -- ненормален. "Естественный ход вещей" -- результат грехопадения. Наш мир -- сломанный мир.

Но Христос "взорвал" ад изнутри, так что теперь у нас есть путь. Мы призваны идти по нему к Небесному Иерусалиму. Кто как может. Не время опускать руки и отчаиваться. Даст Бог, прорвёмся!

> Итак, все — все войдите в радость Господа своего! И первые, и последние, примите награду; богатые и бедные, друг с другом ликуйте; воздержные и беспечные, равно почтите этот день; постившиеся и непостившиеся, возвеселитесь ныне! Трапеза обильна, насладитесь все! Телец упитанный, никто не уходи голодным! Все насладитесь пиром веры, все воспримите богатство благости!

> Никто не рыдай о своем убожестве, ибо для всех настало Царство! Никто не плачь о своих грехах, потому что из гроба воссияло прощение! Никто не бойся смерти, ибо освободила нас Спасова смерть! Объятый смертью, Он угасил смерть. Сошед во ад, Он пленил ад и огорчил того, кто коснулся Его плоти.

https://pravoslavie.ru/61346.html

Христос Воскресе!

# Re: Отцы и дети
std.hugeping
vvs(ping,12) — true-grue
2022-04-16 15:33:33


true-grue> Идет, в том числе, война отцов и детей.

Точно. Иван Сергеевич Тургенев актуален, как никогда.

true-grue> Не получится предложить молодежи жить одним только прошлым, пусть и великим прошлым. Это еще одна проблема.

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

Раньше у государства хоть были организации, ответственные за воспитание. Правда, свою задачу они явно провалили. Хоть я и был членом ВЛКСМ, но ничего хорошего сказать не могу.

# Re: Отцы и дети
std.hugeping
true-grue(ping,43) — hugeping
2022-04-16 12:23:19


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

Я, как ты знаешь, люблю цитировать В.Ф. Одоевского:

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

К слову сказать, тема отцов и детей очень тесно связана с твоим предыдущем сообщением "точка Z". Идет, в том числе, война отцов и детей. Это было хорошо видно в 2014-м, когда сквозило мнение -- "избавиться бы от всех этих пенсионеров, поддерживающих совок, тогда и заживем!". Видно это и сейчас. У известной бабушки, держащей красной знамя, наверняка есть внуки. На чьей они стороне? И кто виноват, если они на стороне тех, которые топчут это знамя? Виновато воспитание? Среда?... Не получится предложить молодежи жить одним только прошлым, пусть и великим прошлым. Это еще одна проблема.

# Отцы и дети
std.hugeping
hugeping(ping,1) — All
2022-04-16 11:42:16


# Вместо введения

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

Но моя заметка про "Точку Z стала политическим манифестом. Как обычно, разбираясь в своих мыслях, одновременно с этим я чувствовал, что обязан высказаться публично. И глядя на мнение людей, которые поддержали меня или, напротив, были разочарованы моей позицией, я понимаю, что поступил честно и по отношению к себе и по отношению к ним. Реакция на "Точку Z" стала своеобразным подтверждением того, о чём я писал. Пусть всё будет честно!

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

# Отцы и дети

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

Во время взросления всегда есть период "бунта". Бунта, как проверки границ. Как попытка преодолеть "ложь" мира, построенного взрослыми. Как попытка родиться в самостоятельную жизнь. Не знаю, я не психолог, но вот этот вот переход -- он ассоциируется у меня с чем-то подобным. Причём, не всегда период совпадает с подростковым возрастом. Например, лично у меня, он длился лет до 35. В этом бунте есть что-то хорошее! Если бунтуешь, значит, тебе не всё равно!

> Когда-то ты был битником...

Но потом проходит время, и ты с удивлением (и даже ужасом!) начинаешь осознавать, что становишься похожим на своего отца. А твои дети -- на тебя самого, n-лет назад. Причём и своего отца ты начинаешь понимать всё больше.

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

Год 1996-й. Я счастливый возвращаюсь домой. Дома меня встречает отец. Он сидит в кресле в плохо освещённой комнате.

-- Ну что, проголосовал?
-- Проголосовал!

Отец вздыхает и качает головой. Он знает за кого я проголосовал. Конечно, в тот момент меня его вздох скорее возмущает. Ведь я голосовал за новый мир! За свободу! За уничтожение старого, закостенелого, прогнившего мира... А он -- вздыхает!

Но сейчас в этой комнате присутствует ещё один человек. Как и мой отец, он грустно улыбается глядя на 18-летнего юношу.

Да, теперь те выборы препарированы. Мы знаем, что ставка на молодёжь оправдала себя. Голосуй, или проиграешь... Опыт "западных партнёров" сработал безупречно. Холодный расчёт. И романтика молодых людей.

- https://yewtu.be/watch?v=Vd7EjvDHwQw

> ... Песня про то, как поднимается с колен родина, которой, собственно говоря, и нет, которая не то что поднимается с колен, а увязает ... все глубже, и туже, и безысходнее. И при этом петь о том, как родина подымается, — это очень мощно. // Е. Летов

Я долго не взрослел. И мне это нравилось. Молодым быть лучше, чем старым. Поэтому Болотная площадь застала меня врасплох. Помню, как бушевали мои эмоции! Свобода попрана! Это очевидно всем! К счастью, мне хватило ума не идти дальше сочувствующих всхлипов. К тому же, я любил программировать больше, чем читать новости.

Время шло, и мир постепенно показывал свою изнанку. Цинизм мироустройства на планете Земля всё чаще пробивал оборону детства и ... я перешёл в своё взрослое состояние. Вдруг, стали понятны все песни Шевчука. :) Шучу.

А кроме того, с высоты прожитого, начал открываться смысл и многих других вещей, которые происходили со мной и с моей страной.

Если бы сегодня я мог оказаться в той комнате, что бы я сказал себе 18-летнему? Рассказал бы я ему, что его используют силы, цинизм которых он не может себе даже представить? Смог бы я найти слова, чтобы сообщить себе из 2012-го, что не стоит лить слёзы напрасно за людей, для которых ты -- лишь средство?

Нет, ничего не сказал бы. Не нашёл бы слов. Просто вздохнул бы и покачал головой, как мой отец когда-то. Потому что всё идёт своим чередом.

Человек рождается в мир. Взрослеет и первый раз серьёзно сталкивается с ложью. И вот, есть силы, которые предлагают здесь и сейчас всё исправить. Устоять невозможно! Праведный гнев -- очень удобное чувство, которым легко управлять. Конечно, повелители марионеток знают, как им пользоваться. И пользуются. Отрицать -- проще чем строить. Утверждать не надо, достаточно перевести "праведный" гнев в режим отрицания и разрушения. Догадаться, что тебя используют -- значит признать, что мир циничней, чем ты можешь себе вообразить. А в это не хочется верить!

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

Но дети не слышат отцов. Что же остаётся? Воспитывать и держать удар, пока наши дети не повзрослели. Пока у нас ещё есть это время.

P.S. Кстати, а помните "отменённую" песню на Eurovision "Я научу тебя..." Мне она тогда очень понравилась. Послушайте, если не слышали. Культура отмены учит быть "таким как все", но не надо стесняться быть собой. ;)

https://yewtu.be/watch?v=tmAgLGk2jIY

# Re: Точка Z
std.hugeping
vvs(ping,12) — hugeping
2022-04-14 16:03:27


Я иногда читаю американскую прессу. И думаю, что было бы важно отметить один момент: невзирая ни на какую конкретную ситуацию с Украиной или где-то ещё, там всегда есть люди, которые хотят войны. Что бы ни случилось, что бы кто ни делал, им нужна только война до конца, на полное уничтожение. Там не все так думают, разумеется, только вот чья точка зрения победит - сказать невозможно.

Поэтому, я всегда придерживался простого правила: если хочешь угодить всем, то не понравишься никому.

# Re: День космонавтики
std.hugeping
vvs(ping,12) — btimofeev
2022-04-13 14:05:16


btimofeev> "Свой" сертификат есть в Яндекс браузере, насколько знаю. Но не все им пользуются.

"Война на носу, а мы не готовы" (C) Тот самый Мюнхгаузен.

# Re: День космонавтики
std.hugeping
btimofeev(tavern,13) — vvs
2022-04-13 05:13:09


vvs> Через неделю поменяли сертификат на японский (своего нет что ли?).

"Свой" сертификат есть в Яндекс браузере, насколько знаю. Но не все им пользуются.

# Re: День космонавтики
std.hugeping
vvs(ping,12) — hugeping
2022-04-12 21:49:02


Ещё, пока не забыл. Ты вот используешь сертификат Let's Encrypt. А у министерства обороны тоже такой был на сайте. Недавно он вдруг оказался отозван и, без отключения в браузере OCSP, Firefox туда заходить отказывался. Через неделю поменяли сертификат на японский (своего нет что ли?). Есть подозрение, что не только МО таким сертификатом пользовалось. Цензура может быть всюду.

# Re: День космонавтики
std.hugeping
vvs(ping,12) — hugeping
2022-04-12 20:39:38


hugeping> P.S. Конечно, мне теперь очень неприятно находиться на mastodon.social.

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

Вопрос: за чей счёт этот банкет? Интернет уже давно кому-то принадлежит, просто это не афишируется. Пётр, ты же сам жаловался, что Линукс больше не принадлежит народу :) Не будь наивен. Информация - это товар и власть. Такие вещи не могут долго оставаться бесхозными, à la guerre comme à la guerre.

# Re: День космонавтики
std.hugeping
vvs(ping,12) — hugeping
2022-04-12 16:07:56


hugeping> Когда я публикую пост, то этот факт публикуется в мастадоне (а до этого, ещё и в твиттере) + он постится в телеграм канал (который нигде не заявлялся).

Понятно. Никакого чуда значит не произошло. Кто-то пошёл по этой ссылке и пожаловался модераторам. Если банят Госдуму и СМИ, то уж совершенно беззащитного пнуть им сам Бог велел...

То ли дело Zulip. Там в правилах чётко написано, что банят даже если ты нарушил их правила в любом _другом_ месте. То есть зарегистрировавшись ты согласен, что их правила теперь действуют даже у тебя дома! Оруэлл отдыхает.

# Re: День космонавтики
std.hugeping
hugeping(ping,1) — vvs
2022-04-12 15:46:38


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

vvs> А можно пояснить для меня дурака^H^H^H^H^H^H неспециалиста? Этот пост каким-то образом попадает на mastodon или цитируется там?

Когда я публикую пост, то этот факт публикуется в мастадоне (а до этого, ещё и в твиттере) + он постится в телеграм канал (который нигде не заявлялся).

# Re: День космонавтики
std.hugeping
vvs(ping,12) — hugeping
2022-04-12 15:12:29


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

А можно пояснить для меня дурака^H^H^H^H^H^H неспециалиста? Этот пост каким-то образом попадает на mastodon или цитируется там? Потому что иначе выглядит так, что они следят за всеми по всему интернету (что выглядит более шокирующе, чем сама блокировка).

А насчёт свободы слова. Ну, меня забанили ещё несколько лет назад на reddit за совершенно сдержанную критику компании RedHat. Там вообще никакой политики не было. С формулировкой: "недостаточно уважительно" (!) Сапоги не лизал? Получи бан.

# День космонавтики
std.hugeping
hugeping(ping,1) — All
2022-04-12 13:53:45


Вчера я опубликовал свою статью ii://RZlA1xAFOxQMrrPRYC13 "Точка Z"
Потом была DDOS атака (впрочем, я до последнего считал это совпадением).
Потом -- комментарий в gemini. Сейчас пришло вот это:

Ваши посты удалены

===

Было обнаружено, что некоторые из ваших постов нарушают одно или несколько правил сообщества, и они были удалены модераторами mastodon.social.

**Причина:** Содержимое нарушает следующие правила сообщества

- No incitement of violence or promotion of violent ideologies

Цитируемые посты:


> Новая статья на станции ping. Точка Z
> https://club.hugeping.ru/RZlA1xAFOxQMrrPRYC13
>

Просмотр: https://mastodon.social/web/statuses/108109401254905355

---

Я, конечно, не буду комментировать. Всем всё понятно. Также, приглашаю всех сомневающихся почитать посты в мастодоне, помеченные @rf и увидеть, что справедливость -- для всех разная. Но я лично понял для себя две простые вещи:

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

С днём космонавтики, друзья!

P.S. Конечно, мне теперь очень неприятно находиться на mastodon.social. Единственное, что меня сейчас сдерживает, что информацию нужно доносить любыми доступными способами. Но если я всё-таки решу уйти, заходите на https://hugeping.ru

# Re: Точка Z
std.hugeping
hugeping(ping,1) — vvs
2022-04-11 16:57:32


vvs> А я гляжу, народ-то потихоньку мигрирует с иностранных хостингов. И это не по идеологическим мотивам. Если GitHub накроется медным тазом, есть план Б?

Да где разместить код, найдём, конечно. Пока мне просто не хочется ничего ломать: какие-то дистрибутивы уже заточены на github. А так, релизы дублируются здесь, например: https://sourceforge.net/projects/instead/files/instead/

# Re: Точка Z
std.hugeping
vvs(ping,12) — hugeping
2022-04-11 16:14:58


hugeping> А ещё чаще -- ты вообще перестаёшь понимать, что такое хорошо и что плохо.

Всё относительно - зависит от культуры. Людоедство это плохо? А у некоторых племен - это проявление доблести. Опять же можно вспомнить практику рабовладения в античном мире. Некоторые на этом подорвались уже в наше время и начали сносить памятники.

hugeping> Например, можно начать рассуждать в духе, мол, и в СССР была пропаганда и диктатура. Репрессии. И вообще... кто знает, как там было на самом деле?... Такие рассуждения могут привести к отрицанию любой правды на Земле. В этой "ловушке" удобно находиться, потому что ты всегда находишься в позиции отвлечённого наблюдателя, для которого все понятия относительны. И если честно, это состояние мне понятно, потому что я сам в нём когда-то находился.

Хех. Прямо как у моей мамы: "откуда мне знать, как на самом деле?" Я тогда отвечаю, что есть бритва Оккама, т.е. эмпирическое правило, основанное на здравом смысле.

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

И да - всё относительно, пока не выберешь конкретную систему отсчёта, связанную с тобой.

hugeping> Но почему мы считаем, что рациональное -- это и есть подлинная реальность?

Диалектика считает, что у всего есть больше одной стороны. Логика не исчерпывает всё сущее.

hugeping> Это -- мой нерв. Если у вас он работает по-другому, что же... -- мы враги.

Ну да. Так оно и работает на самом деле. Это диктуется не логикой, а верой. Почему многие уверены, что существует только одна истина? Потому что только свою веру они таковой считают. А иначе неизбежны противоречия. Можно ли одновременно поклоняться и Богу и Сатане? Я могу понять, почему людоед жаждет крови, но я точно не хочу, чтобы это была кровь моя и моих близких.

hugeping> Как и любой нормальный человек, я против войны, против гибели людей.

Если сравнить, то и войны тоже бывают разные. Одни за правую веру. Другие - за своих близких. Одни чужими руками. Другие своей кровью. Легко запутаться.

Помню я когда-то давно смотрел интервью небезызвестного Евгения Киселёва на RTVi, когда ведущая сказала, что, конечно, не бывает ничего важнее человеческой жизни. На это Киселёв её шокировал, ответив, что конечно же бывает. Иначе почему люди готовы отдавать за что-то свою жизнь? Вот только слова не имеют значения. Люди часто говорят одно, а поступают наоборот. Слова пусты, словам верить нельзя. Надо всегда учитывать конкретные обстоятельства.

hugeping> Сегодня идёт война мифологий. Конечно, Украина лишь видимая сторона конфликта. Она -- как прокси. И сидящие за прокси понимают, что ставки -- очень высоки. Это пугает. Так ли надёжно ЯО в качестве оружия сдерживания, или цена вопроса "перебъёт" даже инстинкт самосохранения? Боюсь даже думать об этом. Мир трещит по швам. Где окажется каждый из нас?

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

hugeping> Точка Z наступила не 24 февраля, а гораздо раньше. Просто многие из нас этого не заметили. А того, кто заметил -- мы не слушали. Пора просыпаться.

Некоторые уверены, что третья мировая идет уже давно. Я так на одном форуме говорил ещё несколько лет назад, что война началась ещё тогда, когда страны Варшавского Договора начали присоединять к НАТО. Один западный политик заявлял, что не НАТО расширяется на Восток, а это восточные европейцы присоединяются к Западу. А кто их спросил? А они понимали истинный смысл происходящего? Очередные пустые слова.

hugeping> P.S. Понимаю, что моя заметка будет неприятна некоторым из вас. Поступайте как знаете, но "диванную" операцию в комментариях, если она возникнет, я буду зачищать. Моя заметка -- скорее манифест, а не приглашение к дискуссии. Я чувствую, что должен внятно и чётко обозначить свою позицию. И я её обозначил.

Для меня это очередной повод пофилософствовать :) Я уже достаточно взрослый, чтобы не заниматься бесполезными срачами. Если моя философия кому-то не по душе, то я её никому не навязываю.

hugeping> P.S. #2 Уподобляться некоторым разработчикам Open Source проектов я не буду. Так что INSTEAD по-прежнему открытый и интернациональный проект, в котором, кстати, есть и украинская локализация. Он принадлежит сообществу -- совершенно разным людям, которые несут собственную ответственность за свои поступки. Наука, искусство и Open Source должны принадлежать всем! В этом я никогда не сомневался.

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

P.S. И почему это обязательно объединять нынешнюю Украинскую власть со всем её населением? Даже если они не в восторге от происходящего. Там очень разные люди живут и не все могут сейчас откровенно высказывать своё мнение, не опасаясь за свою жизнь. И вообще, история лучше видна через годы. "Блажен, кто посетил сей мир в его минуты роковые" - с этим далеко не каждый согласится.

# Сегодня немного поDDOSили
std.hugeping.micro
hugeping(ping,1) — All
2022-04-11 13:26:23


Сегодня малинку немного поDDOSили. Интересно, что событие это меня как-то "взбодрило" и вообще настроило на позитивный лад. Наверное, тут как с велосипедом. Не до рефлексии. :) Да и вообще -- весело!

Написал быстро скрипт для блокировки нужных IP, перенастроил сервер, ssh. Пока тихо. Конечно, от DDOS нет защиты, особенно, если это RPI на столе. :) Но и ценность моего ресурса невысока, так что в крайнем случае, ну, полежит немного...

# Точка Z
std.hugeping
hugeping(ping,1) — All
2022-04-10 20:18:47


> Лк19:40 Но Он сказал им в ответ: сказываю вам, что если они умолкнут, то камни возопиют.

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

> Мф19:26 А Иисус, воззрев, сказал им: человекам это невозможно, Богу же все возможно.

Переживая за то, что происходит сейчас с народами России и Украины, я в очередной раз понимаю, что в такие "моменты истины" не так важно то, что ты думаешь, как то -- что ты делаешь. Жизнь каждый день ставит перед нами вопросы, на которые нельзя ответить "по шпаргалке". Не удастся остаться в "безопасности". Залечь на дно. Сделать вид, что ничего не произошло... Ведь даже бездействие будет считаться ответом.

> Если есть шаг, должен быть след.

Свой след я тоже оставлю, так устроен этот мир.

Когда горячее олово капает на руку, не до философии. Работает нерв и рефлекс. А что такое "нерв" в данном случае? Это мифология. Мифология не как вымысел или сказка, а как сама жизнь. Мировоззрение, мироощущение, человеческая архитектура. Прошивка. Firmware. (См. "Диалектика мифа", А.Ф. Лосева)

Не так давно я просматривал листовки фашистской Германии, которые сбрасывались во время ВОВ. Смотришь и холодок по коже. Вроде бы ты знаешь, что война в прошлом. Понимаешь, что в листовке написана ложь! Но всё-равно чувствуешь гадкую змеиную ползучую силу, которая затаилась, ждёт своего часа... Ждёт, пока ты дашь слабину.

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

Например, можно начать рассуждать в духе, мол, и в СССР была пропаганда и диктатура. Репрессии. И вообще... кто знает, как там было на самом деле?... Такие рассуждения могут привести к отрицанию любой правды на Земле. В этой "ловушке" удобно находиться, потому что ты всегда находишься в позиции отвлечённого наблюдателя, для которого все понятия относительны. И если честно, это состояние мне понятно, потому что я сам в нём когда-то находился.

Есть такой фильм "Слёзы капали" Г. Данелия. Он снят по мотивам рассказа Кира Булычёва, который в свою очередь есть аллюзия на "Снежную королеву" Г.Х. Андерсена.

В глаз главного героя (Леонов) попадает осколок дьявольского зеркала и при этом тот начинает видеть в окружающих его людях только плохое. Интересно, что при этом он часто фактически прав! Например, он говорит своей жене: "Зачем ты красишь губы? Ты же старая!". Что это, вопрос такта? Ведь с точки зрения рационального, его жена действительно старая. Но почему мы считаем, что рациональное -- это и есть подлинная реальность?

Что такое цвет? Только лишь длина волны? Что видит любящий муж, когда смотрит на свою жену с которой прожил многие годы? Только лишь фотоны? Да нет конечно! Цвет -- это не длина волны. А любящий взгляд -- это не про фотоны.

> Мф6:22 Светильник для тела есть око. Итак, если око твое будет чисто, то все тело твое будет светло

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

> В «их» категориях не существует независимого Донбасса, там нет Новороссии, хоть в качестве отдельного государства, хоть в составе России. Зато там имеются и много весят какие-то очень далёкие от меня вещи, вроде финансовой целесообразности, международных норм и общности экономических интересов. Ещё там существуют «серьёзные люди», которые с удовольствием иной раз пообщаются с чудаками и фриками, но сделают всё равно так, как диктует им их здравый смысл. Их, а не наш. // Захар Прилепин

Когда горят люди в доме профсоюзов, остаться в позиции нейтрального наблюдателя для меня -- это значит -- быть подлецом.

Желать смерти солдатам своей армии -- быть подлецом.

Бить ножом в спину своей Родины, когда ей тяжело -- быть подлецом.

Называть бойцов ДНР и ЛНР террористами -- быть подлецом.

Это -- мой нерв. Если у вас он работает по-другому, что же... -- мы враги. Это печально, но ситуация именно такова. А если вы сомневаетесь, подумайте, что было бы, если бы советские солдаты верили тем листовкам? Думайте, изучайте, читайте. Не скрывайтесь за этим инфантильным "мне стыдно". Прислушайтесь к себе. Что там -- в прошивке? Все мы несём ответственность за наш выбор. Наш след -- это мы сами.

Как и любой нормальный человек, я против войны, против гибели людей. Только вот мир во зле лежит. Ложь, кровь и гной прошлых преступлений невозможно "замолчать". Нарыв вскрылся и пришло время "руками жар загребать". Просто отойти и сказать: "Это не моё"? Нет, ребятки, мы все в одной лодке.

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

Сегодня идёт война мифологий. Конечно, Украина лишь видимая сторона конфликта. Она -- как прокси. И сидящие за прокси понимают, что ставки -- очень высоки. Это пугает. Так ли надёжно ЯО в качестве оружия сдерживания, или цена вопроса "перебъёт" даже инстинкт самосохранения? Боюсь даже думать об этом. Мир трещит по швам. Где окажется каждый из нас?

Точка Z наступила не 24 февраля, а гораздо раньше. Просто многие из нас этого не заметили. А того, кто заметил -- мы не слушали. Пора просыпаться.

Для поднятия морального духа:

- книга "Письма с Донбасса" // Захар Прилепин
- https://t.me/patricklancasternewstoday Патрик Ланкастер
- https://vk.com/video-3156562_456244781 Призраки: солдаты забытой войны
- https://yewtu.be/watch?v=augFYP09ALQ Облака плывут над головой
- https://yewtu.be/watch?v=aEkqA5L2hl0 Мы не уйдём // Джанго

P.S. Понимаю, что моя заметка будет неприятна некоторым из вас. Поступайте как знаете, но "диванную" операцию в комментариях, если она возникнет, я буду зачищать. Моя заметка -- скорее манифест, а не приглашение к дискуссии. Я чувствую, что должен внятно и чётко обозначить свою позицию. И я её обозначил.

P.S. #2 Уподобляться некоторым разработчикам Open Source проектов я не буду. Так что INSTEAD по-прежнему открытый и интернациональный проект, в котором, кстати, есть и украинская локализация. Он принадлежит сообществу -- совершенно разным людям, которые несут собственную ответственность за свои поступки. Наука, искусство и Open Source должны принадлежать всем! В этом я никогда не сомневался.

# Re: Александр Столяров о творчестве
std.hugeping.micro
vvs(ping,12) — mukranenburg
2022-03-27 14:07:58


mukranenburg> не надо доказывать, надо отстраняться не нужного.

Вот в этом и разница между физиками и лириками.

# Re: Александр Столяров о творчестве
std.hugeping.micro
hugeping(ping,1) — mukranenburg
2022-03-27 10:32:00


mukranenburg> Писал музыку к Старцу Паисию, знаком со Столяровым. Красота и идеи, они в простоте.

Ого!

> На обсуждении фильма один молодой критик сказал: как так о святом и в виде комедии и под звуки гармошки?

Вообще, фильм можно назвать "псевдодокументальным". Так что, как не крути, это в первую очередь художественное произведение. А критики, они такие. :)

Мне вот понравился "монах и бес", хотя ортодоксально говоря, ситуация там описанная - невозможна. Но фильм получился добрым.

Почему вспомнился? Наверное, из-за самоиронии. В обоих фильмах это есть. Как противоядие против фальши.

# Re: Программирование как зависимость
std.hugeping.micro
mukranenburg(ping,42) — hugeping
2022-03-27 07:13:05


Как сделать телефон на Андроиде приемником стереосигнала по блютуз? Есть передатчик, но похоже в телефоне нет стереоприемника блютуз, как в переносных мини колонках? Задача: передать на телефон звук от стереомикрофона. 🙂 и если это получится то будет выгодный проект!)

# Re: Александр Столяров о творчестве
std.hugeping.micro
mukranenburg(ping,42) — vvs
2022-03-27 07:06:01


Писал музыку к Старцу Паисию, знаком со Столяровым. Красота и идеи, они в простоте. На обсуждении фильма один молодой критик сказал: как так о святом и в виде комедии и под звуки гармошки? Александр чуть задумался и говорит: Вы слишком серьезно и строго к себе относитесь!)) не надо доказывать, надо отстраняться не нужного. Дорого дня!

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2022-02-19 08:49:47


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

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

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

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

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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2022-02-04 10:18:16


>> Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ.
shaos> Есть смысл, если надо заслать что-то маленькое вместе с сообщением (бинарь программки например, или заархивированный исходник).

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2022-02-04 10:18:13


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

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

>> Да и не повод дальше усложнять.
shaos> Это небольшие инкрементальные улучшения, которые могут вывести IDEC на орбиту современных технологий ;)

Пока не понял как :)

>> Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)
shaos> Ну для начала - добавляет бинарных данных в рассылки.

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

>> С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею.
shaos> Ну почему? Есть разница 100% сообщений надо вычитать, чтобы отфильтровать из них бинарные объекты или 1.56%? ;)

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

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

Сдаётся мне, что это зависит от реализации. Например, в цезии формат простой, заточенный на линейное чтение базы сообщений. Тут O(n), согласен. А если хотя бы по сообщению на файл, то уже всё таки O(1).

# Re: Нодлист
idec.talks
Ordos(tgi,1) — Andrew Lobanov
2022-01-25 13:37:05


Тогда спешу сообщить, что через пару дней станция tgi переезжает на домен tgistation.ru.

Не суть какое событие, но для порядка отписать обязан.

# Нодлист
idec.talks
Andrew Lobanov(tavern,1) — All
2022-01-24 05:31:03


Не прошло и двух месяцев, как я собрал актуальный нодлист.

Лежит в таверне на публичных фреках. Налетай!

P.S.: Доступен через веб-интерфейс http://idec.spline-online.ml/ без регистрации и SMS.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2022-01-21 09:32:52


ake> Добавил на своей ноде.

Это, безусловно, замечательно. А теперь как наладить отправку сообщения поинтом твоего узла поинту моего узла? :)

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

# Re: Александр Столяров о творчестве
std.hugeping.micro
vvs(ping,12) — hugeping
2022-01-16 14:24:10


hugeping> Мысль о том, что когда-нибудь мы все вдруг проснёмся, кажется не такой уж и неверотяной... ;)

Бывает такое ощущение, иногда до боли. Для киберпанка - "Матрица", "13-й этаж". А для религиозных людей - страшный суд?

# Re: Александр Столяров о творчестве
std.hugeping.micro
hugeping(ping,1) — vvs
2022-01-15 16:34:11


vvs> Вспоминается ещё анекдот:
vvs> ... Очнувшись, он с ликованием подумал об удачном исходе столь трудного и опасного опыта и, дрожа от нетерпения и пережитого, поспешно развернул бумажку с драгоценной записью. На ней он прочел; “Банан велик, а кожура еще больше...”

Забавно! Не раз испытывал похожее во сне. Когда "гениальная мысль" оказывается бредом. :) Тем удивительней контраст по сравнению с ощущением озарения во сне. Мысль о том, что когда-нибудь мы все вдруг проснёмся, кажется не такой уж и неверотяной... ;)

# Re: Александр Столяров о творчестве
std.hugeping.micro
vvs(ping,12) — hugeping
2022-01-06 22:43:01


hugeping> Смотрю фильм про Александра Столярова (знаю его по фильму "Старец Паисий и я, стоящий вверх ногами").

Ещё один Столяров? ;)

>> Я вам говорил, что разницы между Копполой, мной и кинолюбителем из Житомира нет никакой. По большому счёту, это вопрос пиара...

Это всё так, но есть нюансы. Или, как гласит известное высказывание, дьявол кроется в деталях. А так, с философской точки зрения, конечно, на все сложные вопросы всегда существует один общий ответ: "все там будем" или "все под Богом ходим" (C)

У Эйнштейна тоже есть на эту тему соответствующее высказывание: "Вряд ли можно отрицать, что высшей целью всякой теории является сделать элементарные основные элементы настолько простыми и их число настолько минимальным, насколько это возможно без того, чтобы потерять адекватное представление даже одной частицы опыта". Поэтому я и потерял интерес к спекулятивным философским теориям. Слишком общие рассуждения уже лишены всякой практической пользы и становятся тривиальными.

Вспоминается ещё анекдот:
Как-то раз американский физик-экспериментатор Р.Вуд (1868—1955), довольно эксцентричный человек, любитель всяких острых ощущений, решил проделать на себе рискованный опыт — испытать действие наркотика. С большим трудом раздобыв опиум, он накурился этого зелья и вскоре впал в забытье. Придя через некоторое время в сознание, он вспомнил, что, находясь в одурманенном состоянии, напал на какую-то чрезвычайно глубокую и важную научную идею, но на какую именно — начисто вылетело из головы. Тогда Вуд решил повторить опыт в надежде, что ему посчастливится вновь обрести ускользнувшую мысль.
И действительно, как только начало сказываться наркотическое действие опиума, забытая мысль не замедлила возникнуть в уме ученого. Чувствуя, что сознание вот-вот покинет его, Вуд сумел в последний момент сконцентрировать волю, записать идею на бумажке и впал в беспамятство. Очнувшись, он с ликованием подумал об удачном исходе столь трудного и опасного опыта и, дрожа от нетерпения и пережитого, поспешно развернул бумажку с драгоценной записью. На ней он прочел; “Банан велик, а кожура еще больше...”

# Александр Столяров о творчестве
std.hugeping.micro
hugeping(ping,1) — All
2022-01-06 19:24:13


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

https://www.youtube.com/watch?v=RQ0HKYOR3c8&t=1221s

> Я вам говорил, что разницы между Копполой, мной и кинолюбителем из Житомира нет никакой. По большому счёту, это вопрос пиара...

# 2022
idec.talks
shaos(shaos, 2) — All
2022-01-02 04:23:09


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

# Re: Актуальный нодлист
idec.talks
Ordos(tgi,1) — shaos
2021-12-24 10:31:59


Вот кстати здравая мысль. И фича полезная и ничего не ломает. Я - за.

# Re: Актуальный нодлист
idec.talks
shaos(tavern,34) — shaos
2021-12-24 07:12:14


А кстати небыло мыслей сделать специальный вызов в 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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — hugeping
2021-12-24 06:58:03


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

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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
shaos(tavern,34) — hugeping
2021-12-24 06:56:57


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

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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — hugeping
2021-12-23 19:37:43


> Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

Ну, у меня ключевая идея была как раз в том, что если нам нужно авторизоваться для получения данных, то мы просто дописываем строку авторизации к идентификатору эхи (или сообщения) и не надо вводить никаких новых методов. Нет большой разницы, в плане наличия данных в запросе, обращаемся мы к специальному /u/private/myauth/secret.echo или к стандартному /u/e/myauth.secret.echo. Только с ограничением на имена эх промахнулся.

Без разницы, как это реализовано внутри - генерирует нода такие индексы динамически или честно форвардит входящие.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
hugeping(ping,1) — ake
2021-12-23 09:23:44


ake> Добавил на своей ноде.

ake> На клиенте:
ake> Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
ake> Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

У меня были похожие вещи на старой ноде (на основе iing). У меня было понятие виртуальной эхи. Фактически, через них можно было делать любой запрос. Например, получить личные сообщения, делать поиск по содержимому итд. На текущей ii-go личку сделал проще. Сообщения шлются в эху .private (вообще, эхи с . у меня считаются специальными) и дальше при заборе этой эхи учитывается, что именно можно отдавать юзеру. Решение делается на основе поля To. Там кажется можно даже групповую переписку организовывать, но я сейчас не помню. Но если написать в личку All, то услышат все (через личку). :) Естественно, забор . эх нужен авторизированный. Емнип, /u/point/ расширен для этого.

Но главный вопрос в другом. Как наладить хождение почты между узлами? И тут возникает масса интересных вопросов... Начиная от адресации, маршрутизации и заканчивая вопросами как долго хранить эту переписку транзитным узлам. Ну итд. И тогда я подумал, а так ли нужна эта фича? Мне вот достаточно лички в пределах моего ресурса.

# Re: Мысли про возможное будущее IDEC
idec.talks
hugeping(ping,1) — shaos
2021-12-23 09:11:45


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

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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
hugeping(ping,1) — shaos
2021-12-23 09:02:58


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

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

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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
vvs(ping,12) — shaos
2021-12-22 21:07:52


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

Если бы знал, то не спрашивал бы. Философия, стоящая за idec, для меня не вполне понятна. Я просто пользуюсь тем, что есть, для чисто практических целей.

Сам я никогда не делаю ничего сверх необходимого. Правда мои личные потребности могут кого-нибудь очень удивить, но я никогда и не претендовал на их объективную сущность :)

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
shaos(tavern,34) — vvs
2021-12-22 20:46:44


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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
shaos(tavern,34) — ake
2021-12-22 20:43:51


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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
vvs(ping,12) — ake
2021-12-22 19:33:39


И всё-таки, зачем кому-то и дальше усложнять idec?

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

Кто-нибудь смотрел для сравнения, например, https://public-inbox.org/README.html ? Это очень простой механизм, который использует готовые решения и протоколы для всего. Например децентрализованная сеть там за счёт Git. К тому же оно используется самими разработчиками Git. Кто-то может оценить, в чём возможные преимущества реализации этих же функций на idec заново?

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — Andrew Lobanov
2021-12-22 18:22:03


Добавил на своей ноде.

На клиенте:
Чтобы отправить сообщение кому-то, отправляем его в эху mailto.{имя ноды}.{номер поинта}. Например, mailto.ake.100
Чтобы прочитать свои входящие, указываем для получения ноду mailfor.{строка авторизации}.

В интерфейсе ноды:
Входящие - http://gears.headake.win/idec/ui2/directmail/inbox
Отправить сообщение - http://gears.headake.win/idec/ui2/directmail/send (адрес вводится в обычном формате "nodename, 123")

Реквизиты для тестов
Адрес пользователя: ake, 5
Строка авторизации: jfmq66fj6e

Адрес пользователя: ake, 6
Строка авторизации: 7uyoxz2fj4

О грустном - клиентах и разных подводных граблях.

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

# Re: IDEC identity
idec.talks
shaos(tavern,34) — Difrex(mobile)
2021-12-22 09:14:47


По поводу общих поинтов - 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 если секретный ключ утёк или утрачен, а узел с которого пользователь изначально идентифицировался более не существует (т.е. пользователь не может перепослать новый публичный ключ со старого узла, а должен сделать это с другого узла где сисоп каким-то образом должен удостовериться, что это тот же самый человек, что идентифицировался ранее со старого более недоступного узла - например изначально вместе с публичным ключом должен был быть распространён адрес емейл, который ни в коме случае не должен быть скомпрометирован или что-то типа этого).

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 08:02:49


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

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

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

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

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

ii://1KpcmGrc9pUtZQ6Puv1z

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 07:54:13


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

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

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

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

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

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

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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-22 05:09:30


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

ii-go это анархическая реализация. Взять хоть редактирование сообщений :)

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

Есть ли смысл в таких аттачах? Тело сообщения не должно превышать 64КБ. Может проще аттачи распространять по отдельной схеме, и хэши на аттачи кидать в теги собщения? :)

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-22 05:09:30


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

Реализация всё ещё пишется за несколько часов :) Да и не повод дальше усложнять. Давай пойдём моим любимым путём: какие проблемы ты решаешь? :)

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

С моей точки зрения этот false positive с такой высокой вероятностью ломает всю затею. А найти и прочитать сообщение в общем случае это O(1). Другое дело, что в зависимости от конкретной платформы и конкретной реализации в абсолютных величинах это может быть долго. Я догадываюсь куда именно ты клонишь.

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — shaos
2021-12-22 02:18:44


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

- Чтобы исключить кривотолки и неправильные реализации, надо явно прописать алгоритм создания хэша, который реализован в 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, хотя можно добавить правило парсинга, что между ==== и ==== искать вложения ненадо)...

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — ake
2021-12-22 01:47:34


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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-22 01:38:43


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

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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
ake(ping,30) — shaos
2021-12-21 18:34:00


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

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

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

# Re: Мысли про возможное будущее IDEC
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-21 17:41:54


shaos> Всем привет

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

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

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

Когда доползу до компа, постараюсь ответить более развёрнуто.

# Мысли про возможное будущее IDEC
idec.talks
shaos(shaos, 2) — All
2021-12-21 08:13:05


Всем привет

Я познакомился в 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.talks
shaos(shaos, 2) — All
2021-12-19 11:01:22


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

# Re: Два пустых сообщения в idec.talks
idec.talks
shaos(tavern,34) — Andrew Lobanov
2021-12-20 09:47:45


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

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

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
Andrew Lobanov(tavern,1) — shaos
2021-12-20 09:35:42


shaos> а почему ZX80? это же тормозная недоделка
shaos> программировать надо ZX-Spectrum (aka ZX82)

Похоже, смешались воедино ZX-Spectrum и Z80 %)

# Re: Два пустых сообщения в idec.talks
idec.talks
Andrew Lobanov(tavern,1) — shaos
2021-12-20 09:35:42


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

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

# Два пустых сообщения в idec.talks
idec.talks
shaos(tavern,34) — All
2021-12-20 07:46:43


Существует 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
Наверное если они невалидные их надо в чёрный список, не?

# Re: Актуальный нодлист
idec.talks
shaos(tavern,34) — ake
2021-12-19 12:37:02


Ну и от меня держите :)
{
    "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"
        ],
    ]
}

# Новый узел IDEC http://shaos.net:8085
idec.talks
shaos(tavern,34) — All
2021-12-19 12:35:00


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

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

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

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

Shaos

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
shaos(tavern,34) — hugeping
2021-12-19 11:41:25


а почему ZX80? это же тормозная недоделка
программировать надо ZX-Spectrum (aka ZX82)

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-12-18 06:20:41


AL>> Как это будет работать в масштабе сети?
ake> Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.

Химера какая-то, если честно. Давай чтоль нормальный POC :)

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-12-18 06:17:58


>> Менять сообщения, конечно, никто не запрещает, но не надо такое отдавать наружу никогда. А так - каждый волен со своей базой делать что угодно - хоть удалить вообще нафиг :)
ake> Совсем не обязательно менять сообщения, ничто не запрещает отдавать в индексе эхи, сообщения имеющие другое значение в соответствующем поле. И кросспостинг почти про то же.

Кросспостинг реализуется на стороне клиента и делается совсем иначе и проще. Зачем городить огород?

>> Для этого нужна поддержка шифрованных сообщений.
ake> Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).
>> Возможность редактирования сообщений это зло.
ake> Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"

Ну любые нововведения должны решать существующие проблемы. Изменения ради изменений это путь к сложной системе без смысла.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — Andrew Lobanov
2021-12-17 14:25:06


AL> Как это будет работать в масштабе сети?

Навскидку - либо масштабируем то же самое до нод, т.е. складываем в скрытую эху outbound.some_node_authstr, на которую подписана эта нода; либо форвардим с помощью /u/push.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — Andrew Lobanov
2021-12-17 13:29:52


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

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

> Для этого нужна поддержка шифрованных сообщений.

Тэг с типом содержимого вообще ортогонален шифрованным сообщениям. Можно хоть что слать, заранее перекодировав и указав, что это base64/uuencode/koi8r/etc, если надо (да, будет неоптимально, но это опять организационный вопрос, и я в курсе про файл-эхи).

> Возможность редактирования сообщений это зло.

Обратный вопрос, перефразируя: "Какие проблемы это создаёт?"

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


ake> Но это вопрос транспорта сообщений и api. Ещё есть вопрос обнаружения отправителей и получателей, особенно между нодами, ибо с этим на практике как-то не очень. Есть имя ноды, которое иногда может меняться со временем, по которому нельзя тривиально узнать адрес (видимо для этого предполагается собирать нодлист), а про получателя мы знаем только имя в свободной форме.

Посмотри в поле адреса. Оно не просто так сущетвует, а однозначно тебя идентифицирует в сети. В отличие от имени.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


hugeping>> - личка (правда у тебя в списке этого нет)
ake> Ну, примитивную личку можно собрать на базе идеи про перемаркировку, она там как раз в виде примера.

Как это будет работать в масштабе сети?

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2021-12-17 11:47:57


hugeping> А так, из твоих предложений мне лично интересны:
hugeping> - редактирование.

Является злом в чистом виде и должно быть запрещено законом :)

hugeping> - личка (правда у тебя в списке этого нет)

Есть некоторые идеи и есть потребность в этой фиче.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Andrew Lobanov(tavern,1) — ake
2021-12-17 11:47:57


ake> Доброго времени суток. На волне (пока ещё) энтузиазма решил поделиться "рационализаторскими" предложениями для idec. Некоторые из них, в том или ином виде, озвучивались. Часть из них относится скорее к реализации нод, но некоторые потребуют либо дополнения протокола, либо изменений с разной степенью обратной совместимости.

Ты забыл самое главное написать: какие существующие проблемы это решает?

ake> 1. Правила перемаркировки эх. Идея простая - на ноду приходит сообщение (не важно, фетчится или от поинта) и, если у него в качестве эхи указано некое значение A, то оно заменяется на некоторое A* по определённому правилу. Самый очевидный вариант использования - "личные" эхи, один поинт отправляет сообщение в эху "sendmsg.username", в процессе оно перемаркируется, как "readmsg.username_authstr" и адресат его может получить. Ещё так можно укрупнять и агрегировать эхи, перемаркировывая сообщения из внешних "dev.c", "dev.cpp", "dev.python" в общую локальную "dev.main", например. Недостатком становится то, что такие эхи становятся либо односторонними, либо надо создавать сложные обратные правила (т.е. ответы должны будут помещаться и в новую эху, и в старую).

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

ake> 2. Кросспостинг - отправка и присутствие сообщения с одним ID в нескольких эхах одновременно.

Это задача клиента.

ake> 3. Хуки на появление сообщений в эхе/от пользователя/в качестве ответа. Тогда можно будет сделать, например, эху для управления нодой, какие-нибудь голосовалки (изначально была идея нодо-локальной общественной модерации) и ещё что-нибудь.

Непонятно какие задачи решает. Голосования проводили и без этого. Можно анализировать сабжи. Это дёшево.

ake> 4. Добавить тег определяющий кодировку или тип содержимого (mime-type) тела сообщения. По идее это должно гарантировано решить проблему с тем, как реализовывать шифрование сообщений - зашифрованное сообщение будет иметь соответствующий тег encoding и его расшифровкой должен будет заниматься клиент.

Для этого нужна поддержка шифрованных сообщений. Но я, например, против шифрования в эхах.

ake> 5. Хранить время фетча сообщения нодой и использовать его в качестве указателя сдвига для получения индекса в /u/e-подобном запросе. Я читал обсуждение чего-то подобного в idec.talks, но по-моему там предлагалось использовать время самого сообщения, что действительно может работать криво.

Можно попробовать POC написать.

ake> 6. Метод POST для /u/e и /u/m, это тоже обсуждалось и, вроде, не должно требовать больших изменений, но почему-то не взлетело.

Смысла особого нет. Не решает ни одной проблемы.

ake> 7. Хранить в тегах, кроме указателя на отвеченное сообщение, указатель на первое сообщение ветки обсуждения/топика. Чуть упрощает реализацию топиков и позволяет писать в них сообщения не являющиеся ответами на конкретный пост.

Смысла нет, так как построить цепочку ответов это практически бесплатно.

ake> 8. Пока ещё сырая, на как выходит не новая, идея, касающаяся редактирования сообщений, заключающаяся в отправке нового сообщения, с тегом, скажем, "amend" содержащим ID оригинального сообщения. Идентичная идея была описана ещё в ii://jOO4SZIyVrHLU9XxuhKW , но осталась без ответов.

Возможность редактирования сообщений это зло.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — Ordos
2021-12-17 10:58:57


Ordos> Самое простое

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

Но это вопрос транспорта сообщений и api. Ещё есть вопрос обнаружения отправителей и получателей, особенно между нодами, ибо с этим на практике как-то не очень. Есть имя ноды, которое иногда может меняться со временем, по которому нельзя тривиально узнать адрес (видимо для этого предполагается собирать нодлист), а про получателя мы знаем только имя в свободной форме.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — hugeping
2021-12-17 10:36:50


hugeping> Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)

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

hugeping> - личка (правда у тебя в списке этого нет)

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Ordos(tgi,1) — Ordos
2021-12-17 08:58:36


Забыл добавить по поводу передачи лички между станциями. Лучше не забирать такие эхи, а наоборот пушить на нужную станцию. Таким образом, такие эхи не будут нигде отсвечивать и получить их список становится невозможно. Да и не нужно.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
Ordos(tgi,1) — ake
2021-12-17 08:51:49


Думаю, что не стоит усложнять. Единственное, что может быть действительно полезно - это личка. Но здесь потребуется доработка клиентов. Самое простое - ввести дополнительный запрос с авторизацией на получение личных сообщений/эх. К этому потом можно прикрутить, например, ботов, предлагающих разное.

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

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

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
hugeping(ping,1) — ake
2021-12-17 08:59:36


ake> но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.

Чужой энтузиазм радует! :) Но, откровенно говоря, я наблюдал многих энтузиастов (не только про idec сейчас говорю), которые на волне энтузиаста что-то делали, не доделали и ушли. В этом смысле у меня теперь есть прагматический скепсис, который вылился в то, что я перестал поддерживать всех идейных новичков. Просто потому, что начинаешь помогать, тратишь последние крохи времени (которые берёг для своих проектов) а потом... Всё в пустоту. Вот твоя фраза "делать нечего" она выдаёт именно такое отношение. Извини. :)

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

Но у меня не было цели сделать из idec универсальную технологию. Допустим, у тебя эта цель (не важно, чем она диктуется) есть. Тогда я предлагаю тебе додумать до конца твои идеи и оформить их в виде конкретных предложений стандарта. Обсуждать проще конкретные технические предложения (и отдельно каждое).

Потому что, то же редактирование -- не так просто как кажется в начале.

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

Остальное на мой взгляд избыточные функции и я их вряд ли буду у себя реализовывать.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
vvs(ping,12) — ake
2021-12-16 19:08:26


ake> Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь.

Причина ничем не хуже любой другой.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — vvs
2021-12-16 18:43:07


vvs> Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.

vvs> Сам я не знаю, зачем существует idec, но пользуюсь им для узкого круга общения, не заморачиваясь философскими деталями.

Ну, а вот мне просто он концептуально и технически нравится, как универсальная вещь. Можно, конечно, сказать самому себе: "да нет, это просто группа друзей сделала для себя форум, просто вот так хитро устроенный, _это не для всех_", но это будет разочаровывающим выводом и во многом будет значить, что мне здесь делать, собственно, нечего. Но другого сообщества, использующего idec, у меня нет, а энтузиазм пока есть.

# Re: Предложения или "Как нам обустроить idec?"
idec.talks
vvs(ping,12) — ake
2021-12-16 17:36:05


Подозреваю, что сначала надо задать вопрос: кому и зачем нужен idec? И тогда многие ответы станут очевидны.

То ли idec должен всё включать и поддерживать. И тогда проще взять уже существующие протоколы и софт. То ли все хотят игрушечную реализацию, доступную школьнику. И тогда он может кому-то показаться уже слишком переусложнённым. Кстати, даже в существующих реализациях иногда уже встречались некоторые несовместимости.

Сам я не знаю, зачем существует idec, но пользуюсь им для узкого круга общения, не заморачиваясь философскими деталями.

# Предложения или "Как нам обустроить idec?"
idec.talks
ake(ping,30) — All
2021-12-16 16:22:37


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

1. Правила перемаркировки эх. Идея простая - на ноду приходит сообщение (не важно, фетчится или от поинта) и, если у него в качестве эхи указано некое значение A, то оно заменяется на некоторое A* по определённому правилу. Самый очевидный вариант использования - "личные" эхи, один поинт отправляет сообщение в эху "sendmsg.username", в процессе оно перемаркируется, как "readmsg.username_authstr" и адресат его может получить. Ещё так можно укрупнять и агрегировать эхи, перемаркировывая сообщения из внешних "dev.c", "dev.cpp", "dev.python" в общую локальную "dev.main", например. Недостатком становится то, что такие эхи становятся либо односторонними, либо надо создавать сложные обратные правила (т.е. ответы должны будут помещаться и в новую эху, и в старую).

2. Кросспостинг - отправка и присутствие сообщения с одним ID в нескольких эхах одновременно.

3. Хуки на появление сообщений в эхе/от пользователя/в качестве ответа. Тогда можно будет сделать, например, эху для управления нодой, какие-нибудь голосовалки (изначально была идея нодо-локальной общественной модерации) и ещё что-нибудь.

4. Добавить тег определяющий кодировку или тип содержимого (mime-type) тела сообщения. По идее это должно гарантировано решить проблему с тем, как реализовывать шифрование сообщений - зашифрованное сообщение будет иметь соответствующий тег encoding и его расшифровкой должен будет заниматься клиент.

5. Хранить время фетча сообщения нодой и использовать его в качестве указателя сдвига для получения индекса в /u/e-подобном запросе. Я читал обсуждение чего-то подобного в idec.talks, но по-моему там предлагалось использовать время самого сообщения, что действительно может работать криво.

6. Метод POST для /u/e и /u/m, это тоже обсуждалось и, вроде, не должно требовать больших изменений, но почему-то не взлетело.

7. Хранить в тегах, кроме указателя на отвеченное сообщение, указатель на первое сообщение ветки обсуждения/топика. Чуть упрощает реализацию топиков и позволяет писать в них сообщения не являющиеся ответами на конкретный пост.

8. Пока ещё сырая, на как выходит не новая, идея, касающаяся редактирования сообщений, заключающаяся в отправке нового сообщения, с тегом, скажем, "amend" содержащим ID оригинального сообщения. Идентичная идея была описана ещё в ii://jOO4SZIyVrHLU9XxuhKW , но осталась без ответов.

8.1. В первом варианте реализации, при получении такого сообщения нода либо удаляет оригинальное сообщение полностью (что ломает ответы на старый пост), либо удаляет его только из индексов, и заменяет его ссылкой на новую версию при прямом обращении (и если сообщение редактировалось много раз, то и предыдущие ссылки на него).

8.2. Более кардинальный способ - добавление в формат ID поля/постфикса версии, которое учитывается при фетче (и только при фетче). Тогда новое сообщение перезаписывает старое и инкрементирует версию, клиенты и ноды при фетче тянут сообщение, если его версия новее (что, правда, сильно усложняет его логику), на ответах это не сказывается, т.к. для них ID не поменялся.

# Re: Анонс станции
idec.talks
hugeping(ping,1) — ake
2021-12-15 19:24:52


ake> Сделал открытую регистрацию поинтов на станции, но с небольшим квестом - форма регистрации находится в gemini - gemini://ake.crabdance.com:1966/enroll/intro/

Прикольная идея. :)

# Re: Анонс станции
idec.talks
ake(ping,30) — ake
2021-12-15 18:36:49


Сделал открытую регистрацию поинтов на станции, но с небольшим квестом - форма регистрации находится в gemini - gemini://ake.crabdance.com:1966/enroll/intro/
С одной стороны, думаю, это снизит риски автоматических регистраций и прочих злоупотреблений (а вдруг?), с другой, это будет не особенно большим препятствием, и процедура остаётся автоматической.

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-15 17:15:11


https://github.com/breakintoprogram/lib-spectrum Z80 Library Routines
http://oldmachinery.blogspot.com/2014/04/zx-sprites.html ZX sprites (интересная статья)
http://sebastianmihai.com/libzx.html libzx
https://vtrd.in/book.php Много разных книг

P.S. Edited: 2021-12-15 17:54:47

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
hugeping(ping,1) — hugeping
2021-12-15 16:34:39


https://zxpress.ru/book.php?id=18 Программирование в машинных кодах и на языке ассемблера

# Re: Актуальный нодлист
idec.talks
ake(ping,30) — Andrew Lobanov
2021-12-15 05:42:15


{
    "nodename": "ake",
    "client": "http://gears.headake.win/idec/",
    "web": "http://gears.headake.win/idec/ui2/",
    "sysop": "ake",
    "contacts": {
        "email": "kdeisacake@mail.ru"
    },
    "description": "Ake station",
    "uplinks": [
        [ "ping", "10m" ],
        [ "tavern", "10m" ],
        [ "tgi", "10m" ]
    ]
}

# Re: Программирование под ZX80 на ассемблере
zx.spectrum
vvs(ping,12) — hugeping
2021-12-14 16:22:38


hugeping> К сожалению, очень многие тулзы написаны только для Windows.

Это очень зависит от того, кто именно преобладает в данном сообществе. А в Линуксе, напротив, гораздо больше серверов и средств разработки. Бывает даже интересно сравнивать.

Моё личное впечатление, что это характерно именно для игровых платформ и их эмуляторов и у виндузятников там больше любителей, использующих какой-нибудь Бейсик или C#. А, например, в научных кругах, как правило, используют MacOS или Линукс, а языки совсем другие.