ru.ftn.develop

>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< > This message has been _forwarded_! The original message was: < >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< > Area: *WINPOINT* > From: *Tim Schattkowsky(2:240/1120.29)* > To: *All* > Subject: *WInPoint Beta 7 Available* > Sent: *09.01.22* *17:16:18* >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< ╔═════════════════════════════════════╗ ║ █ █ ████ WinPoint ║ ║ █ █ █ █ Public Beta 7 ║ ║ █ █ ████ (Version 387) ║ ║ █ █ █ █ ║ ║ █ █ █ Released 2022-01-09 ║ ╟─────────────────────────────────────╢ ║ Complete Point Software for Windows ║ ╟─────────────────────────────────────╢ ║ Most notable changes since Beta 6: ║ ║ ∙NEW Default charset per area ║ ║ ∙NEW Support for CP895 Encoding ║ ║ ∙NEW Localized display/mnt. filter ║ ║ ∙NEW Localized area properties ║ ║ ∙NEW Improved Localization ║ ║ ∙NEW Improved Popup rendering ║ ║ ∙NEW TIC now supports "replaces" ║ ║ ∙NEW Various minor improvements ║ ║ ∙FIX Reordering Uplinks,Packers,... ║ ║ ∙FIX Invalid msg date on non-engl. ║ ║ ∙FIX Bad msg colors on first start ║ ║ ∙FIX Crash when new msg empty area ║ ║ ∙FIX Some window order fixes ║ ║ ∙FIX Various minor bug fixes ║ ╚═════════════════════════════════════╝ Hello All, an updated version including important bug fixes is available at http://www.winpoint.org/WP_387.zip Regards, Tim -+- WinPoint 387.0 @ Origin: Original WinPoint Origin! (2:240/1120.29) >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< > End of forwarded message < >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-< Regards, Tim

//Hello Nil,// on *13.12.21* at *21:19:40* You wrote in rea *RU.FTN.DEVELOP* to *Tim Schattkowsky* about *"WInPoint Beta 6 Available"*. N> Nice job. Thanks. N> Is it die hard Win32 app or it uses some modern framework, so N> can be ported? Say its ... classic. Most code is from the 90s. So sure its Win32 :) N> Also, do you distribute the source code? Not currently. I try to do enough cleanup to share it in the future. Regards, Tim

Доброго времени суток, Nil! 08 Jan 2022 01:01:34, ты -> мне: NA>>> Или вот binkd, например. Не знаю, были ли уже в то время NA>>> библиотеки libevent, libev, libuv (это уже новее), AV>> Может, тебе еще и epoll() во всякие смешные системы портировать? :-) NA> Подобная библиотека как раз и создана решать задачу трансляции NA> высокоуровневых асинхронных вызовов во что-то доступно в ОС, NA> например, старый добрый select(2), с его ограничениями, разумеется. Ну и нахрен он такой нужен? Ладно, на фидошный мылер нагрузка никакая, да и справлялись же как-то во времена модемных каналов и мегабайтов ОЗУ... NA> Как пример, Libuv вообще делает асинхронными дисковые операции, NA> которые на epoll() не повесишь, С чего бы вдруг? Дескриптор - он в любом случае дескриптор, а что там за ним - известно только ядру. NA> и всё это эмулируется через пул-воркертредов. Еще и треды... epoll тем и хорош, что все дескрипторы обрабатываются в одном потоке. NA>>> но куча кода для кросс-платформенной работы с сокетами могла бы NA>>> уйти. AV>> Куда и зачем? NA> Вместо того, чтобы пытаться поддержать разные асинхронные сокеты NA> на разных ОС, в виде развесистых #ifdef, можно сфокусировать своё NA> внимание, непосредственно, на имплементации binkp протокола, NA> причём, используя высокоуровневые scatter-gather IO. Протокол уже доведен до функциональной полноты. А привязывать его эталонную реализацию к каким-то библиотекам лучше не надо. NA>>> Ещё там какие-то предупреждения по поводу тредов, надо пользоваться NA>>> форками, AV>> Треды совершенно точно фпень, а с момента появления epoll() - AV>> напомню, это произошло в ядре 2.6 и glibc 2.3 где-то в 2004 году - и AV>> форкаться нужды нет. NA> (a) на сегодняшний день epoll() не используется в коде binkp Там не те нагрузки... NA> (б) epoll() реализован только в Linux, а хочется запускать там, где NA> это делается через kqueue(), А зачем? NA> или через Windows IOCP, Вот разве что... NA> и т.д. А больше живых систем и не осталось. NA>>> Можно, например, научить binkd читать fidoconfig, ведь там линки NA>>> с паролями уже есть, только добавить секцию бинк-специфичных NA>>> опций. AV>> Каких? NA> Все настройки из binkd.conf не относящиеся к линкам, и не NA> дублирующиеся в fidoconfig - их можно поместить как if NA> "[module]"=="bink" Зачем? Единственное, что может иметь хоть какой-то смысл - использовать fidoconfig в качестве password-файла. А информацию о способах соединения получать напрямую из нодлиста. NA>>> А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, NA>>> чтобы противостоять натиску DDoS? AV>> Нахрена это userspace-приложению? NA> Тут скорее не приложение, а демон. Да хоть жопа с ручкой... работает в userspace - значит, приложение. NA> При ограниченности ресурсов, можно сфокусироваться на обслуживании NA> легитимных клиентов, и меньше ресурсов тратить на ботов. Да, NA> юзерспейс приложение также может добавлять правила для ядерного NA> фильтра, Кто его туда пустит? NA> чтобы зловред трафик отшибать сразу там, но все решения принимаются в NA> самом юзерспейс-демоне. Если флуд дошел до приложения, принимать решения уже поздно. -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Чужие темплейты читают только ламеры с IQ<64

Hello, Alexander! Saturday January 08 2022 07:07, from Alexander Kruglikov -> Nil A: AK> @MSGID: 2:5053/58 61d90031 AK> @REPLY: 2:5015/46 61d8bdc9 AK> @CHRS: CP866 2 AK> @TZUTC: 0400 AK> @RealName: Александр А. Кругликов AK> @E-Mail: alexandr (собака) kruglikov (тчк) info AK> @Voice: +7-905-384-4027 AK> @TID: hpt/lnx 1.9 2021-12-02 AK> Привет, Nil! AK> 08 янв 22 01:01, Nil A писал(а) к Alexey Vissarionov: NA>>>> Можно, например, научить binkd читать fidoconfig, ведь там NA>>>> линки с паролями уже есть, только добавить секцию NA>>>> бинк-специфичных опций. AV>>> Каких? NA>> Все настройки из binkd.conf не относящиеся к линкам, и не NA>> дублирующиеся в fidoconfig - их можно поместить как if NA>> "[module]"=="bink" AK> А если я старовер и у меня нет hpt? AK> @TID: hpt/lnx 1.9 2021-12-02 Ты всё врёшь, @E-Mail: alexandr (собака) ! (тут была шутка про собаку). Во-первых, binkd+hpt самая часто использующаяся связка в R50. Во-вторых, если вдруг binkd будет приучен к fidoconfig, то просто в таком формате и будет содержаться его конфиг, начиная от инфы о сисопе и станции, до списка линков с паролями. Да, там не будет эх, файлэх и всего этого от хаски. И, кстати, у тебя тогда будет хороший повод их и добавить, что упростит процесс миграции. Best Regards, Nil

Привет, Nil! 08 янв 22 01:01, Nil A писал(а) к Alexey Vissarionov: NA>>> Можно, например, научить binkd читать fidoconfig, ведь там линки NA>>> с паролями уже есть, только добавить секцию бинк-специфичных опций. AV>> Каких? NA> Все настройки из binkd.conf не относящиеся к линкам, и не NA> дублирующиеся в fidoconfig - их можно поместить как if NA> "[module]"=="bink" А если я старовер и у меня нет hpt? С наилучшими пожеланиями, Alexander.

Hello, Alexey! Friday January 07 2022 10:44, from Alexey Vissarionov -> Nil A: NA>> Или вот binkd, например. Не знаю, были ли уже в то время NA>> библиотеки libevent, libev, libuv (это уже новее), AV> Может, тебе еще и epoll() во всякие смешные системы портировать? :-) Подобная библиотека как раз и создана решать задачу трансляции высокоуровневых асинхронных вызовов во что-то доступно в ОС, например, старый добрый select(2), с его ограничениями, разумеется. Как пример, Libuv вообще делает асинхронными дисковые операции, которые на epoll() не повесишь, и всё это эмулируется через пул-воркертредов. NA>> но куча кода для кросс-платформенной работы с сокетами могла бы NA>> уйти. AV> Куда и зачем? Вместо того, чтобы пытаться поддержать разные асинхронные сокеты на разных ОС, в виде развесистых #ifdef, можно сфокусировать своё внимание, непосредственно, на имплементации binkp протокола, причём, используя высокоуровневые scatter-gather IO. NA>> Ещё там какие-то предупреждения по поводу тредов, надо NA>> пользоваться форками, AV> Треды совершенно точно фпень, а с момента появления epoll() - напомню, AV> это произошло в ядре 2.6 и glibc 2.3 где-то в 2004 году - и форкаться AV> нужды нет. (a) на сегодняшний день epoll() не используется в коде binkp (б) epoll() реализован только в Linux, а хочется запускать там, где это делается через kqueue(), или через Windows IOCP, и т.д. NA>> Можно, например, научить binkd читать fidoconfig, ведь там линки NA>> с паролями уже есть, только добавить секцию бинк-специфичных NA>> опций. AV> Каких? Все настройки из binkd.conf не относящиеся к линкам, и не дублирующиеся в fidoconfig - их можно поместить как if "[module]"=="bink" NA>> А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, NA>> чтобы противостоять натиску DDoS? AV> Нахрена это userspace-приложению? Тут скорее не приложение, а демон. При ограниченности ресурсов, можно сфокусироваться на обслуживании легитимных клиентов, и меньше ресурсов тратить на ботов. Да, юзерспейс приложение также может добавлять правила для ядерного фильтра, чтобы зловред трафик отшибать сразу там, но все решения принимаются в самом юзерспейс-демоне. Best Regards, Nil

Доброго времени суток, Nil! 06 Jan 2022 05:34:24, ты -> Sergey Anohin: NA> Расскажу как ковырялся в husky. Оригинальных авторов, как я понимаю, NA> в сети уже нет, но есть несколько мейнтейнеров. Миша Дукельский NA> недавно там вычистил захардкоженне "константы", типа return 7; if NA> (result == 9), хотя там спагетти код ещё немного присутствует. Это беда не только husky... хорошо еще, если очередной индус (независимо от национальности) вспомнит о препроцессоре и напихает хренову тонну #define - коряво, конечно, но, на мой взгляд, без символьных имен можно использовать только совсем очевидные константы: 0, 1, -1 А по уму для описания констант полагается использовать анонимный enum{} - в качестве приятного побочного эффекта получаем ограничение области видимости. NA> Или вот binkd, например. Не знаю, были ли уже в то время библиотеки NA> libevent, libev, libuv (это уже новее), Может, тебе еще и epoll() во всякие смешные системы портировать? :-) NA> но куча кода для кросс-платформенной работы с сокетами могла бы уйти. Куда и зачем? NA> А, ну OS2 и Amiga поддержки не будет, да и с djgpp может не собраться, NA> вот зачем самим пришлось писать. Сейчас на эти платформы никто и не посмотрит. Что в целом правильно: работы много, пользы мало. NA> Ещё там какие-то предупреждения по поводу тредов, надо пользоваться NA> форками, Треды совершенно точно фпень, а с момента появления epoll() - напомню, это произошло в ядре 2.6 и glibc 2.3 где-то в 2004 году - и форкаться нужды нет. NA> явно какие-то баги с этим связанные, пусть библиотека этим заботится. Самые сердитые баги, какие я видел (да и сам лепил, чего уж), были связаны с тредами. NA> Можно, например, научить binkd читать fidoconfig, ведь там линки с NA> паролями уже есть, только добавить секцию бинк-специфичных опций. Каких? NA> А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, чтобы NA> противостоять натиску DDoS? Нахрена это userspace-приложению? NA> А вот все современные аффтары, что-то какие-то они мне мало NA> симпатичные, к сожалению. "Мелки в наш век пошли людишки..." // (ц) -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Пренебрежение страховкой карается по закону. Всемирного тяготения.

Hello, Nil! NA> 100% с тобой тут согласен. NA> Я понимаю, что одному с нуля труднозатратно, если только это не какая-то короткая утилитка. NA> Я с удовольствием бы коллаборировался с кем-нибудь, но, пока вот никак не случается. С Женей коллаборируйтесь, считай нодософт и гейт ннтп уже есть, правда Женя не любит плюсики :) Правда баз вроде там нет, для этого придется "подружить" husky и fidogate NA> Наверное есть какой-то новый девелопмент, например, научить SMAPI ходить в SQL (правда пока не пойму какие плюсы от этого). Самый очевидный, использовать SQL базы вместо архаичных фидошных. Ты возразишь что есть же SMAPI, но толку от него, нет же модулей php-smapi, nodejs-smapi и прочих интеграций, плюс надо хранить где-то служебную инфу. NA> Можно, например, научить binkd читать fidoconfig, ведь там линки с паролями уже есть, только добавить секцию бинк-специфичных опций. А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, чтобы противостоять натиску DDoS? Идея husky как платформы единой хороша, но думаю что невыполнима, даже rntrack свой smapi использует. NA> А вот все современные аффтары, что-то какие-то они мне мало симпатичные, к сожалению. NA> Ещё удивляюсь, что не найдётся ни одного фронтендщика, который скажет: "я так сильно хочу, но я не понимаю в бакендах" - так мы поможем с бакендами то! А то сами мы, технари, всё как-то меньше с гуями связаны. Таких в фидо нет, все фронтэндщики сейчас это вчерашние девочки-бухгалтерши, и прочий неайти люд, т.к. порог вхождения низок, они и про фидо не знают. SA>> Сам же писал что использовать напрямую фидобазы не получится, т.к. все SA>> равно придется использовать вторую базу для хранения служебной инфы... NA> Я щитаю, что JAM/Squish базы первичны, и в них уже есть вся информация. Можно создать пул-IO-воркеров для работы с диском, к нему уровень кэша, и на одном сервере можно выдержать хайлоад, сильно лучше, чем ходить в SQL. Очень спорно, то есть винтажные базы, ты имеешь ввиду, быстрее современных in memory? Сомневаюсь :) NA> Сбоку можно хранить кэши просто, считай разные индексы, чтобы быстро отвечать на отдельные типы запросов. Кеши и индексы всегда можно выкинуть и перестроить, база остаётся как есть, в JAM/Squish. NA> Даже для ластридеров для разных пользователей есть место в стандартных базах. Только вот пометка на уровне каждого сообщения, прочитано оно или нет - это в базах без привязки к userid. NA> Нетмейл на поентоф можно также хранить в JAM/Squish, и хуком в HPT научить туда натоссивать. Вроде бы вместо огорода из двух баз, проще использовать одну нормальную SQL базу, чтобы не городить огород С наилучшими пожеланиями, Sergey Anohin.

Hello, Sergey! Wednesday January 05 2022 12:01, from Sergey Anohin -> Nil A: SA> Из-за завышенного чсв люди изобретают велосипеды, один кривее другого, SA> так как копаться в чужом коде зашкварь, а сделать с нуля путевую вещь SA> слишком трудозатратно. 100% с тобой тут согласен. Я понимаю, что одному с нуля труднозатратно, если только это не какая-то короткая утилитка. Я с удовольствием бы коллаборировался с кем-нибудь, но, пока вот никак не случается. Расскажу как ковырялся в husky. Оригинальных авторов, как я понимаю, в сети уже нет, но есть несколько мейнтейнеров. Миша Дукельский недавно там вычистил захардкоженне "константы", типа return 7; if (result == 9), хотя там спагетти код ещё немного присутствует. Вообще я не очень люблю ковырять эти старые Сишные проекты, слишком низкоуровнево приходится писать. Я так как бы не против драйверочек там на Си, но если в юзерспейсе надо тупо много работать с текстовыми строчками (то, что делате хаски), то на Си это не так изящно. Наверное есть какой-то новый девелопмент, например, научить SMAPI ходить в SQL (правда пока не пойму какие плюсы от этого). Но опять же, хаски это сплошная дрочня с указателями/индексами по char* и ручные списки с ними (вместо человеческих стрингов, вектор/лист стрингов и алогоритмов работы с ними), толпы циклов с большим количеством состояний (вместо понятных стандартных алгоритмов типа свёртки, фильтров и пр). Или вот binkd, например. Не знаю, были ли уже в то время библиотеки libevent, libev, libuv (это уже новее), но куча кода для кросс-платформенной работы с сокетами могла бы уйти. А, ну OS2 и Amiga поддержки не будет, да и с djgpp может не собраться, вот зачем самим пришлось писать. Ещё там какие-то предупреждения по поводу тредов, надо пользоваться форками, явно какие-то баги с этим связанные, пусть библиотека этим заботится. Можно, например, научить binkd читать fidoconfig, ведь там линки с паролями уже есть, только добавить секцию бинк-специфичных опций. А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, чтобы противостоять натиску DDoS? А вот все современные аффтары, что-то какие-то они мне мало симпатичные, к сожалению. Ещё удивляюсь, что не найдётся ни одного фронтендщика, который скажет: "я так сильно хочу, но я не понимаю в бакендах" - так мы поможем с бакендами то! А то сами мы, технари, всё как-то меньше с гуями связаны. SA> Сам же писал что использовать напрямую фидобазы не получится, т.к. все SA> равно придется использовать вторую базу для хранения служебной инфы... Я щитаю, что JAM/Squish базы первичны, и в них уже есть вся информация. Можно создать пул-IO-воркеров для работы с диском, к нему уровень кэша, и на одном сервере можно выдержать хайлоад, сильно лучше, чем ходить в SQL. Сбоку можно хранить кэши просто, считай разные индексы, чтобы быстро отвечать на отдельные типы запросов. Кеши и индексы всегда можно выкинуть и перестроить, база остаётся как есть, в JAM/Squish. Даже для ластридеров для разных пользователей есть место в стандартных базах. Только вот пометка на уровне каждого сообщения, прочитано оно или нет - это в базах без привязки к userid. Нетмейл на поентоф можно также хранить в JAM/Squish, и хуком в HPT научить туда натоссивать. SA> Ну и там есть противники похорон офлайн режима наверно Оффлайн можно свести к кешированию впрок на стороне читалки. Под iOS NNTP читалка Newstap - она соединяется и вытаскивает вообще все статьи и отключается. В этом смысле теряется сквозная интеграция с ластридерами правда. Best Regards, Nil

Hello, Nil! NA> Вот сейчас, без троллинга, и без обзывания меня Мицголом-второе-пришествие, я вывалю сюда дизайн, для затравки. Ты уж много раз писал об этом, Многа букв :) Все ж готово уж, сам же предлагал вебвьюхи к wfido у которого и апи есть :) Из-за завышенного чсв люди изобретают велосипеды, один кривее другого, так как копаться в чужом коде зашкварь, а сделать с нуля путевую вещь слишком трудозатратно. Увы, либо найдется нормальный человек лишенный чсв, либо второе, ничего нового нет. У первого события больше вероятность. Сам же писал что использовать напрямую фидобазы не получится, т.к. все равно придется использовать вторую базу для хранения служебной инфы... Ну и там есть противники похорон офлайн режима наверно С наилучшими пожеланиями, Sergey Anohin.