> а что будет, если создать новую эху?
> +++ Caesium/0.4 RC1

Вообще, это было отключено. :) Но, похоже, не до конца.
Оставлять эху? Если да - как назвать?

Короче, пока подписал как "Старое железо"

Тут станция понимает аттачи в base64.

Вот тут написано:
http://hugeping.tk/rOf069UX8K24yAzvWa9N#rOf069UX8K24yAzvWa9N

Можешь отредактировать своё сообщение, и тогда по http можно будет просто скачивать этот архив.

P.S.
Ну или разреши мне, я сам сделаю.

(upd: изменена ссылка)

> файл-то я у себя выложу, а вот наскальный аттач останется навсегда :)

У меня это на отображение только влияет. Сообщение такое-же, в тело прямо внедрено base64.. Но перед ним стоит строка (тег @base64: имя файла) и нода, при показе через http(s) сделает ссылку на скачку файла прямо из тела письма, чтобы не заниматься самому декодированием. А так - то же самое сообщение, просто одну строку в тексте добавить и всё.

> ага, я видел такое в описании, но подумал, что текстом каноничнее

А, ну ок. Я на всякий случай сказал.

> а у сообщения id после редактирования изменится? оно ко мне новое придёт?
> я то из текстового клиента сижу :)
id не меняется и сообщение не придёт. Это, на самом деле, вопрос вообще к ii/idec - поддержка изменения сообщений. Наверное, если делать, это многое усложнит. (Надо чтобы новый id как-то ссылался на старый, может тегами?)

Сейчас это просто добавление новой версии в базу, а http морда показывает всегда новую версию.

> а так, я у себя просто грохну файл эхи и заново всё скачаю
Я отредактировал, теперь в http версии можно просто ткнуть на ссылку и скачать. А в "сырой" - base64

По поводу разных систем на старом железе.

Есть у меня eeepc 1000px. Не сказать, что совсем старый. Atom N450, 1Гб памяти. Лет 10 ему.

После долгого перерыва, попал ко мне в руки. Пробовал там NetBSD, Haiku, OpenBSD, alpine Linux.

Haiku работала прилично. Остальные (брал текущие, последние версии) -- вроде терпимо, но только до иксов.

Например, netsurf (gtk версия) сразу пожаловался на нехватку памяти. Скорее всего, потому что был вариант с gtk. Прикол в том, что на этом же нетбуке когда-то крутилась убунта, и не жаловалась.

В итоге, я поставил на него 9front (форк Plan9). Правда, чтобы всё заработало, мне пришлось портировать wifi/ethernet драйверы из OpenBSD и ещё попатчить кое-что по мелочи. Зато теперь, нетбуком действительно интересно пользоваться! И памяти хватает! (Хотя, на сборку последних версий golang её не хватило).

> Круто. Обзоры были? Или будут?

Пока написал вот это: ii://zu9dMH3tSs5i1GP7bq4y

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

> А golang поддерживает этот процессор?

Старая версия собралась, по крайней мере. Та, что ещё на си. (1.04)

> Странно. gtk2-версии вообще работали прилично.

Вот и я не понял, что это было. В любом случае, рад Plan'у. Очень интересная система. :) В 9front, кстати, и питон есть (какой-то старый. правда).

(upd: изменена ссылка на эту эху, оригинальная zu9dMH3tSs5i1GP7bq4y)

btimofeev> Поставил себе OpenBSD второй системой. Изучаю понемногу.

btimofeev> Почему-то у меня в ней Firefox постоянно падает (при этом создает дамп файл, чем его можно изучить?). А Хромиум работает стабильно, но очень долго запускается, раза в 4 медленнее, чем на линуксе.

Пишу в тему спустя 4 года. :)

Я не так давно себе на eeepc поставил NetBSD. И должен сказать, что у меня есть ощущение некоторого "перехайпа" openbsd. NetBSD ничем не хуже! Просто -- скромнее. Почему сложилось такое впечатление?

- Безопасность из коробки openbsd иногда мешает. Приходится, например, отключать перелинковку ядра на перезагрузках и те самые параметры, которые приводят к падению firefox (сейчас уже точно не помню, что именно). В NetBSD это не нужно;

- Насчёт тормозов OpenBSD - подтверждаю. По ощущениям, на слабом и новом железе -- заметно медленнее Linux. На NetBSD я этого не заметил;

- Минимализм и простота OpenBSD -- есть и в NetBSD! Может быть, не так экстремально, но очень близко;

- По функциям, бывает, в NetBSD есть то, что в OpenBSD не сделали т.к. "не нужно". Пример сейчас уже не вспомню, но что-то было при настройке pppoe. Ну или более контрастный пример -- поддержка trim. Которую в OpenBSD так и не сделали (не нужно?), а в NetBSD она есть. Хотя в контексте старого железа -- действительно не нужно. :)

В общем, системы довольно близкие по "ощущениям простоты", но в утилитарном смысле для старого железа NetBSD подходит не меньше (а, возможно, и больше!). По крайней мере, если ваше железо поддерживается.

P.S. Забавно, что дефолтный оконный менеджер в OpenBSD это cwm, а в NetBSD ctwm. И оба - неплохие!

В общем, я поднял свою ноду - персональный арт-проект: http://hugeping.tk

Сейчас идёт синк с http://club.syscall.ru , но я буду его закрывать...
Прошу всех, кто с меня фетчит, переходить на http://hugeping.tk и отписаться о возникновении проблем.

Испытываю по живому. :)

За одно сливаю теперь свои материалы с разных источников. Хочу, чтобы хранилось всё в одном месте.

Написал базовую документацию. На этом пока всё, буду потихоньку развивать ноду, но уже не так экстемально. :)

Если кого-то будут интересовать детали, расскажу или дополню доку.

https://github.com/gl00my/ii-go/blob/master/README.md

> У тебя почему-то в топиках количество сообщений выводится на одно меньше, чем сообщений в топике на самом деле

Не заметил в чате.

Я специально вычитаю 1. Как это сделано на punbb форуме. Типа это ответы на пост. Не считая заголовок. 0 - нет ответов.

В принципе, фича, но можно поменять в коде....

> Просто тогда в колонке это надо назвать не посты, а ответы, наверное.

Согласен, завтра сделаю.

>> @base64: имя файла - всё, что после этой строки берется как base64 аттач демка тут
> Т.е. этот тег должен находится в конце тела сообщения?

Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

> Фетчу тебя. Пока все идет нормально.

Отлично! :)

> Главное, чтобы в x/c правильно отображалось :)

Очень надеюсь, что багов не будет. Хотя опыт показывает, что когда всё работает сразу, это означает наличие скрытых багов. :)

> Да. Все что после него это base64. Вообще, может быть стоит сделать по другому. Я сделал как было проще...

Вообще, я думал про начало/конец тега base64. И в веб версии это будет шикарно, в том числе и для картинок. Но если такое внедрять в консольные клиенты, всё-таки, одно сообщение - один base64 аттач - это более понятная и простая схема...

В любом случае, если назреет какой-то стандарт на эту тему, попробую поддержать. :)

> С base64, спойлерами и остальным возитесь пока сами

Так это относится только к Web части. С этим возятся поинты моей ноды.

> 1. Нужно всё-таки объединять усилия .... Кому-то из вас двоих нужно от своей репы отказаться и идти мержить код в общий котёл

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

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

Шрифты вообще не заданы нигде. Никакие. Так что используется тот шрифт, что стоит у тебя в настройках. :)

P.S. Edited: 2020-09-12 17:48:59

Хотел было забрать блог difrex, но:

$ curl https://dynamic.lessmore.pw/idec/u/e/difrex.blog
difrex.blog
error: Internal error

> Предлагаю прописать font-family: sans-serif в body-блок CSS-ки. Это сработает на всех платформах, и разница станет заметна невооружённым глазом. Попробуй хотя бы ради эксперимента

Вообще, я пробовал. Но тут такое дело. Я не хочу навязывать sans/sans-serif. Я сам из тех, кто долго верил в теорию вреда "шрифтов с засечками". А потом попробовал засечки, и мне понравилось. Поэтому я не хочу навязывать стиль шрифта. Пусть отображается дефултная настройка браузера. Те, если у тебя стоит в дефолте шрифты с засечками, ты их и увидишь. Есть вопрос с мобильными браузерами, там такой настройки нет... Ну, что поделать.

>> Примечание: production-реализации нод заменяют в полученной base64-строке плюс (+) и слэш (/) либо их аналоги (- и _) на буквы "A" и "Z" соответственно, дабы убрать из msgid спецсимволы.

Это про msgid речь же. А вопрос вроде касался того, в каком формате поинт шлёт бандл на ноду (POST или GET, не важно). И в каком формате отдают/получают бандлы ноды.

В стандарте есть такая фраза: (все серверы обязаны принимать как обычный, так и urlsafe-словарь, генерируются же бандлы в формате обычного base64)

Для меня эта фраза непонятна. Бандлы вроде в обычном base64, но принимать я должен в любом? Надо детектить тип base?

Я так и не понял, в каком варианте base64 я должен принимать и отдавать бандлы нодам и принимать бандлы от юзера. В итоге имеем такие варианты:

Мой:
1) Я принимаю и отдаю нодам бандлы в обычном base64 (не считая msgid, который подвергается преобразованию описанному в стандарте)

2) принимаю post/get запросы от поинтов в urlsafe base64

И вроде это работает, по крайней мере со станцией Андрея.

difrex:

1) принимает от поинтов обычный base64 но предварительно заэскейпченный

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

> Да, именно так, надо детектить, но это просто делается: всего лишь прогоняешь строку через замену символов, заменяя спецсимволы по словарю.

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

Можно рассказать алгоритм?

Достаточно ли замены:

msg = strings.Replace(msg, "-", "+", -1) /* if it is URL base64 */
msg = strings.Replace(msg, "_", "/", -1) /* make it base64 */

И потом декодировать стандартным base64? Но там вроде еще есть заполнение в виде ===?

> Fixed
Теперь есть другая проблема. Возможно, с моим фетчером.
В выводе у тебя нет последнего перевода строки. То-есть, на запрос -1:1, к примеру, приходит MsgId без \n. Как к этому относиться? Нужно ли мне переделывать?

> Хм, вот про newline в конце интересно. Это у нас нигде не описано, но и проблем ни у кого не возникало

Нужно решение комитета. )
Мне не сложно подправить, но это именно будет хак. Дополнительный блок условный. Заметил только благодаря адаптивному фетчу, который делает пробы по 1 id. Так бы просто последнее сообщение бы не взял и всё.

> А почему так? Я код не хочу ща читать - лень, но ты разве не разбираешь ответ в слайс? Типа,

Почему так, вопрос, который я тоже могу задать: "Разве ты не делаешь просто Printf каждого из id? Зачем вырезать последний \n?

Дело в том, что я старался писать строго. Строка с переводом строки - это однозаначность. Например, пустая строка - это тоже пустая строка и \n.

В системе, когда у нас последняя строка не содержит \n, мы не можем отличить ситуацию, прочиталась ли строка целиком?

Например, вот функция, которая используется везде при работе с сетью:

func http_req_lines(url string, fn func(string) bool) error {
	resp, err := http.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close()
	reader := bufio.NewReader(resp.Body)
	for {
		line, err := reader.ReadString('\n')
		if err != nil && err != io.EOF {
			return err
		}
		line = strings.TrimSuffix(line, "\n")
		if err == io.EOF {
			break
		}
		if !fn(line) {
			break
		}
	}
	return nil
}

Обрати внимание, что if err === io.EOF стоит ПЕРЕД fn(line).

А вот правка, чтоб сработало с твоей нодой:

                if err == io.EOF {

			if line != "" { /* no eol in last line? broken node? */
				fn(line)
			}
                        break
                 }

Если же я перенесу fn(line) перед err == io.EOF, то fn(line) будет вызываться для последнего \n у других нод, которые делают \n в каждой строке.

Я лично считаю, что \n быть должен, но в как бы мы не решили, это должно быть прописано в стандарте, кмк.

> Т.е. я считаю, что "\n" - это разделитель списка и если в конец вносить его, то получится, что последний элемент списка - это всегда пустая строка.

Мой довод, в основном, будет таким.

В UNIX все текстовые файлы традиционно заканчиваются на \n.

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

Стандарт POSIX определяет строку так:

> 3.206 Line
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Зафиксируем это и не ошибёмся. :)

> У меня тоже. Но это все таки данные не совсем для человека.

Ну как, curl можно автоматизировать. Я так и делал, когда переносил данные с ноды, генерировал скриптом запросы, парсил вывод. Удобнее с \n это делать.

> Ты же не будешь править тело сообщения поинта если оно пришло без \n в конце, а просто запишешь в базу.

Лучше я промолчу о том, что я делаю с сообщением поинта, а то вы меня тут заклюёте =)

> // Newline в конце добавлю, но фетчер у меня умеет и так и так.

Угу, отпишись тогда, я от тебя хочу взять fetch difrex.blog (ну и назад забирай тогда её у меня =)

Сделал исправление тоже, поставил на тебя фетч (blog.difrex). Ожидаю взаимного фетча. ;)

Меня убедили начать комментировать код. :)

Так что постепенно буду это делать. На данный момент описал функции в msg.go -- это базовые функции для манипуляции бандлами (decode/encode) и приём сообщений от поинтов.

https://github.com/gl00my/ii-go/blob/master/ii/msg.go

Там от меня ушли 7 сообщений из черновиков/неотправленных? мобильного клиента... Нужно их блеклистить:

ii://2NszlFTgvhakzz7dIfvc
ii://Q03NcPZRuqeaOT5d6Tze
ii://v48ZAPJMiFbWl68YiFWU
ii://5JdRzlDtEJTfOtKCtTb4
ii://pEtdZQ4aPz7SAhFK3zwR
ii://SglNQOG3vyujcZLXjDtu
ii://flYuqUgR5SVgybdnYnVp

Извините. :)

Привет, All!

Как думаете, есть ли смысл думать а внесении в стандарт возможности редактирования сообщений?

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

Может быть, есть смысл сделать что-то вроде такого:

- Редактирование, это создание нового сообщения, с новым msg id;
- В тегах этого сообщения прописан msgid сообщения, которое оно заменяет.

Тогда клиенты, которые не поддерживают этой фичи просто получат новую копию.

Но что делать с отображением этих двух (или больше) сообщений? Скрывать при визуализации "заплаточные", но раздавать их по fetch? Как-то странно...

Что думаете? Есть ли смысл думать в эту сторону, или это только усложнит простую технологию?

Мне кажется, это всё слишком сложно для идеи ii, но может у кого-то будут ещё варианты? Редактирование сообщений, всё-таки, полезная вещь в быту...

Ещё вариант: как то вести отдельно список отредактированных сообщений, и тогда те, кто поддерживают такую фичу, просто скачают эти сообщения повторно и добавят в свои списки... Ну, списки сделать как u/e, ещё одну схему...

AL>> Да. RSS нынче не в почёте.

btimofeev> Видимо RSS заменили всплывающие уведомления от сайтов в браузере. Кто-нибудь использовал такое?

Принципиально не использую. Раньше когда-то случайно где-то нажал и сильно задалбывало.

Привет. В виртуалке когда-то смотрел и колибри и менуэт.
Восхищает, примерно как восхищает демосцена.
Но в практическом смысле - не применял.

Создал новую эху, посвящённую Plan 9.

Не знаю, будет ли жить, но пока так. Раздаётся пока с http://hugeping.tk.

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

Интересное совпадение. У меня работала и на eeepc и на thinkpad и на настольном PC...

Привет!

Погрузился тут в gemini и понял, что эта технология отлично дополняет idec.
А вы как думаете?

Написал пост на эту тему в ii://std.hugeping
ii://p1c3ltDDAoaFciX04W2I

Веб ссылка: http://hugeping.tk/p1c3ltDDAoaFciX04W2I/1

Суть технологии в двух словах.

* Как допиленный gopher;
* UTF-8;
* Есть куча серверов и браузеров.

Новый адрес: club.hugeping.ru или club.hugeping.tk

По hugeping.ru/hugeping.tk будет мой личный блог.

Если кто-то фетчит, поменяйте пожалуйста.

P.S. Edited: 2021-03-13 20:21:37

Вообще, круто! Сам хотел что-то делать подобное, но времени на всё не хватает.

А на чём проект написан?

> С отображением сообщения есть особенность - текст сообщения завернут в преформатированный блок, чтобы разметка не ломалась,

С форматированием проблем нет. Я писал себе форматер, он как раз берёт мои сообщения из idec и постит в виде блога на gemini://hugeping.tk

Вот этот код: https://github.com/gl00my/ii-go/blob/master/ii-gemini/main.go#L49

ake> Следуя девизу "каждому пользователю сети по станции" организовал собственную.

Привет! Тут тихо. Но, надеюсь, IDEC ещё шевелится. :)

ake> Пока нет веб-интерфейса, можно использовать gemini-гейт - gemini://ake.crabdance.com:1966/

lagrange пишет, что срок действия сертификата истёк.

>> Тут тихо. Но, надеюсь, IDEC ещё шевелится
ake> Не было бы это шевеление конвульсиями, будет жалко.

Ну, я лично получил от idec то, что хотел и даже без оглядки на наличие других станций. Моя нода ii-go стала единым источником данных для gemini капсулы и моего блога в вебе. А также для телеграмм каналов. И все это просто текст.

ake> А есть ли какие-то мысли о его перспективах и, страшно сказать, развитии?

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

ake> Но чем дальше думал, тем менее обоснованной казалась идея (несмотря на концептуальную близость сетей) - писать сообщения из gemini не выйдёт;

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

ake> Тогда ведь получается, что по существу IDEC, как протокол, и как сеть, практически ортогонален этим применениям.

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

ake> Я даже не столько о стандарте, хотя там тоже можно много чего придумать и сделать, а о сообществе. Всё-таки в сети с десятком пользователей можно хоть TCP over avian carriers брать, было бы что обсуждать.

В разное время здесь была разная активность. Сейчас всё выглядит полумёртвым, если честно. Но я в основном сконцентрирован на своём проекте/блоге, так что меня это не сильно беспокоит. Ну как и присутствие в gemini -- мне нравится и этого достаточно.

Сегодня выложил документацию: https://github.com/gl00my/ii-go
Также, сменил формат лент с RSS на Atom.

Информация о станции ping: ii://rOf069UX8K24yAzvWa9N

Блог: https://hugeping.ru
Капсула в gemini: gemini://hugeping.ru

Движок INSTEAD: http://instead.hugeping.ru
Парсерный минимализм: https://parser.hugeping.ru

Некоторые из моих игр: https://instead.itch.io
Все игры на INSTEAD можно найти здесь: http://instead-games.ru

github:
https://github.com/hugeping
https://github.com/instead-hub

Telegram: https://t.me/hugeping
Jabber: hugeping@404.city




P.S. Edited: 2023-11-06 15:01:13

Добро пожаловать на станцию ping!

Станция ping - авторский проект Петра Косых (hugeping) ( ii://ay2xlGQxSQ0tZQqXwwku ). Функционирование станции ping не связано с поддержкой каких-либо проектов или общественно-полезной деятельностью. Станцию следует воспринимать как личный проект для самовыражения, который развивается в соответствии с видением его основателя в режиме жёсткой диктатуры.

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

Движок форума называется ii-go: https://github.com/hugeping/ii-go

Станция ping - один из узлов в сети idec: https://github.com/idec-net/new-docs/blob/master/main.md

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

Каждая из лент/эх доступна по RSS, так вы можете отслеживать новые сообщения.

Ниже приводится краткая справка по форматированию сообщений в ii-go.

Если вам нужно вставить код. Начните его со строки ==== и закончите строкой ====

print("Hello, world!")

Далее рассмотрим остальные теги (каждый из них представлен исходным кодом и представлением в сообщении.

@spoiler: Это спойлер!

!релйопс отЭ :reliops@

> Это цитирование

> Это цитирование

P.S. Это комментарии
// И это тоже

P.S. Это комментарии
// И это тоже

# Это заголовок
## Заголовок 2
### Заголовок 3
=== Или используйте для заголовков символ =

# Это заголовок
## Заголовок 2
### Заголовок 3
=== Или используйте для заголовков символ =

Вы можете вставлять картинки в формате xpm2 или xpm3 прямо в тексте. Но помните об ограничении на размер. Изображения до 128x128 в палитре 64 цветов скорее всего подойдут. ;)



Вы можете загрузить себе автар в профиле, тоже скопировав xpm файл в форму. Где делать xpm? Точно умеет gimp.

И, наконец, вы можете сделать аттач файла - написав специальный тег и имя файла, а затем скопировав данные в формате base64:

@base64: logo.png
base64 данные до конца сообщения

logo.png

Когда кто-то редактирует сообщение, то в базу добавляется новая версия этого сообщения. Я добавил в ii-tool команду clean, которая удаляет все старые версии сообщений и сокращает размер базы.

Команду стоит применять во время выключенного сервера ii-go.

Долго думал, какую favicon поставить для узла. В итоге, остановился на этом:

Поменял поведение клика на дату сообщения на главной странице.

Теперь клик приведёт вас к последним 100 сообщениям в выбранной эхе. Тогда вы не пропустите новые сообщения из других топиков.

Чтобы вернуться в привычный вид топиков - нажмите на символ # у сообщения (перейти к сообщению) или на название эхи в шапке ноды.