Peter> Не выжил Рома. :(Был один из немногих участников ЛОРа, которого было интересно и приятно читать. RIP.
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Peter> Не выжил Рома. :(Земля пухом...
> Нужна помощь!
> Не мне.
> Подробности тут: https://www.linux.org.ru/forum/talks/14713493Не выжил Рома. :(
vit01>>> Насчёт лимита в 64 килобайта я против :)Ну так оно нормально как бы ещё.
AL>> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)
Difrex> У меня в 512к лимит в nginx стоит.
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
vit01>> Насчёт лимита в 64 килобайта я против :)
AL> В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)У меня в 512к лимит в nginx стоит.
+++ картошки хватит на всех
vit01> Насчёт лимита в 64 килобайта я против :)В общем, предлагаю компромисс: ограничение делать, но килобайт в 256-512. Я за последнее =)
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
vit01>> Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.
vit01>> Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.
AL> Парсинг штука тяжёлая, но зачем обходить текст построчно, если рендеришь регулярками и в html?Цитаты съедаются регулярками, а вот блоки кода и превьюшки для режима чтения, где цитирование съедается - построчно.
Кстати, этот алгоритм я у тебя позаимствовал откуда-то
vit01>> Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.
AL> Это гипотетические рассуждения или ты действительно ловил такой спам?Насчёт 10 000 сообщений это было тогда, когда по невнимательности я решил скачать содержимое всех эх целиком.
А так да, гипотетически. Ведь если дать возможность юзерам лепить огромные сообщения, то ей обязательно будут пользоваться. Кто-нибудь возьмёт и решит, что это невероятно прикольно взять 5-мегабайтную картинку, закодировать её в base64 и прилепить к своему сообщению. И всем остальным потом это скачивать (особенно через мобильный интернет).
AL> Опять таки: давай попробуем это реализовать в тестовом режиме и посмотрим сколько спама будет сыпаться? Не умозрительно, а именно в реальных условиях.Спам - это всегда человеческий фактор. Когда нас здесь 5 человек, мы можем развлекаться как хотим и не задумываться о том, к чему это может привести.
Вот я сейчас написал выше про картинки в base64 и наверняка отпугнул людей от того, чтобы проделать такое в реале :)
Поэтому смысла особого нет, но вместо этого можно провести стресс-тест на тестовой ноде.
AL> Реальной пользы от этого ограничения нет. Только теоретическая.Лимит какой-нибудь всё равно должен быть. Какое-то разумное, но при этом конечное число.
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
vit01>>> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.Спасибо. Что-то я проглядел =)
vit01>>> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01>>> https://ii-net.tk/idec-doc/?p=protocol
AL>> В стандарте этого нет.
vit01> Вот я тебе скинул ссылку на стандарт, на нашу же документацию, там чётко написано, процитирую ещё раз:
>> GET /u/point/pauth/tmsg или POST /u/point
>> ...
>> В случае POST параметры называются так же: pauth и tmsg.
vit01> Поддержка POST была всегда, ещё со времён Ромы.
vit01>>> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.Парсинг штука тяжёлая, но зачем обходить текст построчно, если рендеришь регулярками и в html?
AL>> Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.
vit01> Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.
vit01> Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.
vit01> Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.Это гипотетические рассуждения или ты действительно ловил такой спам?
vit01>>> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.Опять таки: давай попробуем это реализовать в тестовом режиме и посмотрим сколько спама будет сыпаться? Не умозрительно, а именно в реальных условиях.
AL>> А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.
vit01> Так у ответственных нододержателей есть лимит ещё и на количество зарегистрировавшихся в день, и на количество сфетченного в день.
vit01> Не будет одного сообщения в мегабайт. Будут сразу же 1000 сообщений по 10 мегабайт каждое, и твой клиент упадёт, прогружая их все в оперативку и раскрашивая цитаты. Или будет так тормозить, что им невозможно будет пользоваться.
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
vit01>> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01>> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01>> https://ii-net.tk/idec-doc/?p=protocol
AL> В стандарте этого нет.Вот я тебе скинул ссылку на стандарт, на нашу же документацию, там чётко написано, процитирую ещё раз:
> GET /u/point/pauth/tmsg или POST /u/pointПоддержка POST была всегда, ещё со времён Ромы.
> ...
> В случае POST параметры называются так же: pauth и tmsg.
Можешь глянуть вот сюда, это первая версия ii-php, коммит от 6 апреля 2014, даже тут оно есть, потому что в стандарте было зашито изначально:
https://github.com/idec-net/ii-php/commit/c5b7d89b28520d189631f20a72deb0c4a9c35054
vit01>> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.
AL> Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.
Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.
Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.
vit01>> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.
AL> А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.Так у ответственных нододержателей есть лимит ещё и на количество зарегистрировавшихся в день, и на количество сфетченного в день.
Не будет одного сообщения в мегабайт. Будут сразу же 1000 сообщений по 10 мегабайт каждое, и твой клиент упадёт, прогружая их все в оперативку и раскрашивая цитаты. Или будет так тормозить, что им невозможно будет пользоваться.
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
vit01>>> Мы уже давно хотим ввести нетмейл, но всё никак не договоримся :)В стандарте этого нет.
AL>> Я планирую им заняться сразу после того, как в очередной раз подниму вопрос о u/point через POST-запросы и отказ от ограничения на 64 килобайта =)
vit01> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01> https://ii-net.tk/idec-doc/?p=protocol
vit01> Насчёт лимита в 64 килобайта я против :)Это я знаю.
vit01> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.
vit01> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Peter> Молоток! Радуюсь и немного завидую по хорошему. :)Завидовать здесь нечему, на самом деле. Везде есть свои трудности и свои косяки.
vit01>> Матан, дифференциальные уравнения, теормех, электричество и магнетизм
AL> Срашные слова %)Да, именно без буквы "т"...
Но повезло - значит повезло, хех
Anotheroneuser> Теперь буду считать, что ты можешь проектировать космические корабли!Нее, ну до такого ещё крайне далеко. Чем больше осознаёшь и видишь, как оно устроено на самом деле, тем больше понимаешь, что на абстрактных моделях далеко не уедешь, и что для проектирования чего-то серьёзного нужно невероятно много усилий кучи людей.
Тем более, оценки - это не реальная мера знаний, а, скорее, мера того, что тебе не лень лишний раз поднять зад и чё-то поделать =)
А со знаниями, как обычно, всегда туговато. Но, что ж, буду работать над этим
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
vit01>> Мы уже давно хотим ввести нетмейл, но всё никак не договоримся :)
AL> Я планирую им заняться сразу после того, как в очередной раз подниму вопрос о u/point через POST-запросы и отказ от ограничения на 64 килобайта =)Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
https://github.com/idec-net/ii-db-utils/blob/master/sender.py
https://ii-net.tk/idec-doc/?p=protocol
Насчёт лимита в 64 килобайта я против :)
Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.
Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
> Матан, дифференциальные уравнения, теормех, электричество и магнетизмТеперь буду считать, что ты можешь проектировать космические корабли!
vit01> Все четыре экзамена сдал на 5Поздравляю! Я за свою жизнь ни одну сессию не сдавал так =)
vit01> Матан, дифференциальные уравнения, теормех, электричество и магнетизмСрашные слова %)
vit01> Скольких нервов это стоило! Но зато теперь буду стипендию не 3500 получать, как четвёрошник, а 5000Господин ПЖ приказал радоваться(зачёркнуто) Ништяк. На самом деле это очень круто.
vit01> Сабж!
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
vit01> Все четыре экзамена сдал на 5
vit01> Матан, дифференциальные уравнения, теормех, электричество и магнетизмМолоток! Радуюсь и немного завидую по хорошему. :) Самое интересное -- впереди. :)
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
AL>> ...Нужно не прятаться, а делиться. Для разобщения есть целый интернет, а мы тут для другого.Ну так просто организатор создаёт эху (достаточно отправить письмо в несуществующую и сервер её создаст) и пользуется.
Anotheroneuser> Всё верно, так и есть. Но могут же некоторые мысли быть неподготовленными, преждевременными.
Anotheroneuser> Допустим, когда люди снимают кино, не делятся же они подробностями съёмки. В таком духе))сайты
+++ IDEC-Mobile +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
AL> ...Нужно не прятаться, а делиться. Для разобщения есть целый интернет, а мы тут для другого.Всё верно, так и есть. Но могут же некоторые мысли быть неподготовленными, преждевременными.
AL> Вообще, считаю скрытоэхой всё, чего нет в list.txt =)В догонку. Рома говорил иногда правильные вещи. Нужно не прятаться, а делиться. Для разобщения есть целый интернет, а мы тут для другого.
+++ IDEC-Mobile +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Anotheroneuser>>> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?
AL>> Напиши анонс, например, в эху idec.talks. Там уже пользователи клуба сразу подтянутся, а остальные по мере подключения других узлов сети.
vit01> Какая же это тогда скрытоэха? Если название эхи известно, то мы всё так же общаемся у всех на виду.Не обратил внимания чтт речь о скрытоэхе.
Вообще, считаю скрытоэхой всё, чего нет в list.txt =)
+++ IDEC-Mobile +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Anotheroneuser>> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?
AL> Напиши анонс, например, в эху idec.talks. Там уже пользователи клуба сразу подтянутся, а остальные по мере подключения других узлов сети.Какая же это тогда скрытоэха? Если название эхи известно, то мы всё так же общаемся у всех на виду.
Анонсировать скрытоэху надо по другим каналам связи, не по idec. Ну или асимметричным шифрованием, если хочется прямо здесь
+++ Отправлено через IDEC Mobile +++ GNU/Linux, Android, physics, MLP:FIM
Anotheroneuser> Кстати, я подписался на скрытоэху. Как мне теперь передать её остальным?Напиши анонс, например, в эху idec.talks. Там уже пользователи клуба сразу подтянутся, а остальные по мере подключения других узлов сети.
+++ IDEC-Mobile +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
> да и некуда больше протискиваться, потому что клочок пустоты за решеткой уже давно заполнен оцинкованными гробами с жизненным опытомВ.Пелевин "Чапаев и Пустота".
AL> Ну idec позволяет производить обмен информацией по любому каналу передачи данных. Хоть флешками. Просто пока что интернет это самый доступный вариант.Ого. Тогда idec действительно лучше. Я и не знал, что так можно.
>>> А при чём тут почтовая рассылка?Эхх, вот что значит "недостаточно знаний".
Anotheroneuser>> Мне почему-то казалось, что она — быстрейший способ и можно начать пользоваться ею прямо сейчас.
AL> Ну как альтернатива рассылке здесь и сейчас есть эха. Не требует участия третьей стороны или настройки своего почтового сервера.
+++ Caesium/0.4 RC1
Воспоминания о фидо или "меня зовут 2:/5054:74.20" 2018-11-08 01:19:17 - Evgeniy Shumilov Если оглянуться назад и попытаться ответить на вопрос, по какому периоду своей жизни я тоскую больше всего и в какой период прошлого я хотел бы отправиться на денёк-другой в гости, то наверное это будет примерно второй-третий курс университета. Почему именно туда? Множество новых знакомых, первая работа, первые отношения, погружение в программирование и linux, появление первых телефонов, корявые ява-приложения, подключение витухи на 64к, посиделки с друзьями, дни рождения, записи песен, дача, сборка сервера внутри дивана, и отдельным пунктом - фидо. Фидо - это удивительное явление. Если бы не было фидо, на интернет я бы смотрел совершенно другими глазами. Сейчас интернет через призму моего восприятия представляет из себя огромную такую помойку, долину мусорных куч, среди которых где-то на горизонте высятся небоскрёбы больших корпораций - гугла, яндекса, IBM, огромные грязные мегалиты коммуналок "Вконтакте" и Facebook, обветшалый LiveJournal, с доброй половиной заколоченных окон, дом престарелых "Одноклассники"... И в тени этих живых и доживающих огромных и не очень зданий, копаются в мусорных кучах бобики. Огромное количество бобиков в бессчётном количестве куч. Кто-то радостно похрюкивая кушает какашки, кто-то эти какашки воспроизводит в комментариях, кто-то пытается найти ценную и косточку той или иной степени свежести. У кого нюх получше - те находят то, что искали, остальные плещутся в отходах, обмазанные рекламой казино, курсов игры на форексе и предложением купить настоящий айфон за полцены.В фидо всё было не так. Какие-то отдельные струны души задевает воспоминание о виде GoldEd под досом на CRT мониторе. 80 символов в ширину, 25 в высоту - всё как положено. Никаких жидких кристаллов, никаких SSD, только звуки модема, похрустывание винта (тогда оно было намного громче, чем на нынешних) и желтеющая клавиатура WinKeys c DIN разъёмом. Из сентиментальных чувств всё ещё хранится у мамы системник с Pentium 233 MMX под Socket 7, Sound Blaster 16 и модемом USR на 56к, на котором так и остался настроенный фидопакет тех времён. Эдакая живая капсула времени. Когда ностальгия совсем уж возьмёт меня за горло - сотру с него пыль и буду ночь напролёт перечитывать личку и эхи, возвращаясь в собственную молодость.
+++ Caesium/0.4 RC1 +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
>> Зачем рассылка при общении тет-а-тет?Ну так уже есть эха =)
Anotheroneuser> Ну если будет общий тет-а-тет
>> Как быть с почтой, когда IDEC будет использоваться без интернета?Ну idec позволяет производить обмен информацией по любому каналу передачи данных. Хоть флешками. Просто пока что интернет это самый доступный вариант.
Anotheroneuser> Это для меня уже сложный вопрос, потому что я не знаю, как IDEC можно использовать без интернета..
>> А при чём тут почтовая рассылка?Ну как альтернатива рассылке здесь и сейчас есть эха. Не требует участия третьей стороны или настройки своего почтового сервера.
Anotheroneuser> Мне почему-то казалось, что она — быстрейший способ и можно начать пользоваться ею прямо сейчас.
+++ IDEC-Mobile +++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.