#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

onon Точно говорю, у нас какая-то жопа с транспортами.

orignal рассказывай что с ней

onon Только что наблюдал картину, как у всех стримов ( штук 30) одновременно начал расти RTT

onon Они все при этом через разные туннели

onon Подскочил больше 6 сек RTT прмерно на 8-10 сек

orignal ну значит канал забит был

onon Нет

onon Даже не близко

onon Там 100мбит канал

orignal не факт что именно у тебя а не дальше у провайдера маршрутизатор лагал

orignal это в теории

orignal а на практике могут быть тормоза

onon Ну вот такие задержки и могут тормозить служебный траффик

orignal ну и что тут сделаешь?

onon Хз

onon Вариант с провайдером, возможен, хоть и маловероятен.

onon Буду дальше наблюдать.

onon Попробую параллельно пинговать клирнет

orignal я уже высказал мысль

orignal дело не в объеме трафике а в чисде соединений

orignal которые маршрутизатор опсоса и не держит

onon1 Да ну

onon1 Как-то не реалистично

orignal ну смотри

orignal там поиск для пакета длеается по таблице

orignal а если каждлый новый пакет на другой адрес а не на предыдущий

orignal естественно он подтормаживает

orignal мне вообще кажется за i2p скоро начнут пизды давать

onon1 Нет, там спец. процы стоят, заточенные под это

orignal из-за числа соединений подл нагрузкой

onon1 Торренты же ещё не забанили

orignal у торрентов мало линков

orignal там десятки ну может сотни

orignal а у нас тысячи

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

Vort на баг похоже

Vort но как ловить - не знаю

Vort это может быть та же проблема, которая даёт одновременные фейлы тестов туннелей

Vort "<onon1> Как-то не реалистично" - потому, что большое количество соединений - постоянно, а лаги - изредка

onon Vort, давай стримы переделывать, чем раньше мы их сделаем, тем лучше.

Vort если словить такой баг, то это несколько строчек исправить обычно, а эффект от такого исправления масштабный и стабильный

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

onon С тем CC который сейчас в SSU2 там вероятны Congestion Collapse и spurious retransmissions

Vort да и если стримы разогнать в присутствии багов, то сеть может вообще загнуться

onon Поставим лимит в 64кбайта

onon =)

onon Хватит всем

onon Благо, теперь есть такая врзможность

orignal кстати проблема только с SSU2 или с NTCP2 тоже?

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

Vort скоращать дифф другими словами

Vort сокращать*

onon Нет, там нужны революционные изменения, эволюция там бессильна.

onon И проблема скорее с SSU

Vort orignal: я полагаю, проблема может быть вообще где угодно

orignal например?

Vort ну при перекидывании данных между потоками к примеру. но я детально не разбирался

orignal так там просто io_service.post

orignal как правило

Vort "<onon> Нет, там нужны революционные изменения, эволюция там бессильна." как сказать. революционным должен быть переход от управления окном на основе потерь к управлению на основе задержек

Vort хотя и то и другое, наверно, можно одновременно применять

Vort остальные же изменения мне кажутся не главными и могут быть вполне эволюционными

Vort так как я мало в этой теме разобрался, то точно сказать не могу, но мне кажется, что само ядро такого изменения (контроля) очень большим быть не должно

Vort было бы хорошо оттестировать самую основу, убедиться в работоспособности главной идеи, а потом уже добавлять детали

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

onon Там нет сотен изменений

onon Изменения касаются только отправки по одному пакету, и регулирования скорости отправки по RTT

onon В остальном ничего не менял

onon Ну и ещё смену туннелей ускорил

onon Ну и обработка NACKов сильно улучшена

onon Вроде всё.

Vort вот ещё два примера эволюционных изменений: расчёт RTT (он всё ещё кривоват) и детект/корректная обработка смены туннелей

Vort можно эволюционные вначале, революционные потом; можно наоборот

Vort но всё вместе - не стоит

Vort каждый тип изменения ведь надо по-своему оценивать

Vort какой-то общей оценки "хорошести" работы найти не получится

Vort то есть, сделать изменение - подтвердить тестами, что оно даёт именно такой эффект, какой нужен и какой ожидается; затем делать следующее

onon По твоему я просто от балды там все наговнокодил, и даже не запускал ни разу?

Vort прошу прощения за занудность и "теоретичность", но без этих шагов ожидаю проблемы

onon Ну из всего "набора" можно исключить разве что смену туннелей. Всё остальное даёт эффект только совместно.

onon Потому что в старом CC туннели перегружались постоянным ростом окна, массовыми ретрансмитами и одновременной отправкой больших пачек пакетов.

onon Если из этой троицы что-то "починить" заметного эффекта не будет

onon Оставшиеся проблемы сведут улучшение на нет.

onon И вообще мне странно, что приходится это объяснять.

Vort "<onon> По твоему я просто от балды там все наговнокодил, и даже не запускал ни разу?" результатов тестов по различным (соответствующим конркретному изменению) критериям я не видел

Vort создалось (возможно ошибочное) ощущение, что оценка была по принципу "похоже, стало лучше"

onon Лось, тут можно матом ругаться?

Vort "<onon> Если из этой троицы что-то "починить" заметного эффекта не будет" измерять так проще, говорю же

onon И проявлять неуважение к собеседнику?

onon Нынешний CC может через 6 хопов давать скорость в 1мб/с с минимальным RTT?

Vort окей, один критерий - максимальная скорость. это я помню

Vort насчёт минимальности RTT - как это измерять, если он прыгает туда-сюда?

orignal <dr|z3d> no idea as yet, they just appeared en masse.

orignal <dr|z3d> all running i2pd 0.9.58, XU or XR.

orignal дрозд говорит опять мелкочленные китаезы атакуют

orignal <dr|z3d> <zzz> about 3x the 0.9.58 routers we had on sat., from 6 to 18 % of net. China from maybe 1% to 10%

orignal <dr|z3d> smells like in the last 24h.

Vort я говорил, что провал рейта может быть не из-за последних изменений )

Vort 6 хопов - это рандом, как я понимаю. там и скорости и RTT могут отличаться в десятки раз. как тестировать?

Vort часами гнать поток, измерять максимальную скорость, делать изменение в коде, опять на несколько часов ставить тест?

onon Именно так.

onon Последний месяц я занимался именно этим

Vort это лишь один из критериев. а их - дохрена

onon Лось, он меня провоцирует.

orignal вот чего опять мелочленным надо?

orignal на что?

onon Vort, какие задачи должен выполнять CC?

onon На грубость

Vort увеличить скорость и что-нибудь параллельно сделать хуже - довольно просто. как от этого защититься, как тест организовать?

orignal поятно какие

orignal слать с максимальной скоростью не засирая сеть

Vort onon: не пихать больше, чем может влезть

onon Ну вот, старый с этим не справляется

onon А новый справляется

onon В большинстве случаев

Vort второй критерий - RTT/горбы - как проверял степень "справляния"? как старого кода, так и нового

orignal ну старый не отптимально но сеть не засирал

Vort я вот построил графики и увидел всё те же горбы. как убедиться, что у нового алгоритма горбы меньше/реже/... ?

onon У тебя есть сервис, с которого постоянно кто-то что-то качает?

onon Вот посмотри на стримах RTT

onon Я посмотрел и со старым и с новым

Vort среднее что ли в конкретный момент времени?

Vort если да, то скорость среднюю при этом смотрел?

Vort по тому же методу - мгновенному срезу по всем стримам

onon На старом RTT непрерывно растёт и отаётся на высоких значениях

Vort на рандом хопах что ли ?

onon На новом он определяет BDP и жмёт с максимальной возможной скоростью, не перегружая

onon На реальной сети

onon А не на локалхосте

Vort на своих быстрых узлах то есть?

Vort по моим тестам видны были именно "горбы", так я их всё время и называл

Vort горб - он потому горб, что начинается и заканчивается

Vort видимо, залипания на высоком RTT - это отдельный эффект

onon Если это не стартовый тест, значит кто-то перегружает туннель

onon Кто-то со старым CC

onon Или датаграммами срёт

Vort я про вот эту фразу говорю "<onon> На старом RTT непрерывно растёт и отаётся на высоких значениях"

onon Именно так

Vort я такое горбом не называл бы

onon Потому что налил в буферы на промежуточных роутерах

onon И дальше прёт

Vort вот горб: paste.i2pd.xyz/?a937ffc02948cd3d#FNRaN295bQk5dZvoN9ESCqvTbgURqdSPCMvmTgmhY3K8

Vort если не попасть на "нужный" момент времени, так его вообще можно пропустить

Vort в остальное время пинг вполне нормальный

Vort а вот это, наверно, залипание: paste.i2pd.xyz/?c652b7aff03517b9#2aHWJSEWBGM63j6RsDDrLWt9bth8DSx7xbSM74S8memz

Vort "<onon> И дальше прёт" - с условно постоянным RTT что ли?

Vort я часто после такого залипания видел обрыв

onon С постоянно растущим до отказа

onon До смены туннеля

onon Потому что как видишь, у тебя на графике пакетлосса нет

onon Поэтому CC не срабатывает

Vort ну тогда это не "остаётся на высоких значениях"

onon Ну и всё это время до отказа нужно перегружать туннель?

Vort а смена туннеля как раз родит "горб", точнее одну из его разновидностей

Vort да я просто думаю, как более-менее математически описать успешность регуляции

Vort чтобы можно было поставить числовую оценку алгоритму

Vort глянуть средний пинг по всем туннелям - это лучше, чем ничего. но вот достаточно ли - хз

Vort ещё один метод оценки - посчитать количество смен туннелей для каждого из алгоритмов (при том же самом методе смены)

Vort если предполагаем, что рост RTT часто заканчивается сменой туннелей, то количество смен туннелей должно показывать, насколько часто растёт RTT

orignal да он свалил

Vort orignal: как ты считаешь - каким образом нужно сравнивать алгоритмы CC ?

orignal по количесту NACKов

orignal чем меньше их прилетает тем лучше

orignal ну а с другой стороны

orignal классическая зададчка линейного программирования

orignal как я помню по универу и предмету исследование операций

Vort а нормальность RTT / неразрастание очередей как измерить?

Vort учитывая что RTT прыгает постоянно, даже при идеальной работе

orignal это крайне непростой вопрос

orignal об этом целые тома научных трудов написаны

Vort "<~orignal> классическая зададчка линейного программирования" имеешь в виду объединение нескольких оценок?

orignal собственно RTT отпределяет как часто мы делаем перепосылки

Vort оптимизация в многомерном пространстве

orignal ну задача на эксремум компизиции целевых функций

orignal всекие тачки парето и прочая чушь

orignal ты то явно это изучал недавно

orignal а я старпер и ничего не помню чему учили в универе

Vort ну, то есть, оценки по разным критериям всё же желательно сделать?

Vort я просто не пойму реакции onon

orignal ну человек излишне эмоциаональный

Vort то ли я слишком занудничаю, то ли у него терпения не хватает понять, о чём я говорю

orignal ну он грубо говоря сделать окно максимально большщим

orignal но это уже было 10 лет назад ))

orignal дед долго ругался что я зафлудил всю сеть )))

Vort если это всё - ценные юзерские данные - то так и должно быть

Vort а если мусор/перепосылки - тогда проблема, да

Vort получаем ещё один критерий, получается - сколько мусорим?

Vort просто если я в обсуждениях дойду до 10-20 мерного пространства, то onon точно матом ругаться начнёт )

orignal ну тут ведь как

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

orignal если ничего не слать то и мусорить не будешь ))

Vort :))

orignal правильный криетрий это отношение мусора к полученным данным

Vort в процентах, я это и имел в виду, но не сказал

Vort получается три основных критерия - скорость, равномерность RTT и процент перепосылок

orignal именно так

orignal многопараметрическая оптимизация короче

Vort с равномерностью RTT ещё как-то связаны обрывы, но обрывы и сами по себе бывают, конечно

Vort и неравномерность RTT бывает без обрывов

orignal это уже лаги узлов

Vort если равномерность RTT - наша цель, то крайне желательно как-то почётче её определить. "всегда узнаю, когда вижу" (горб на графике) - не годится

orignal так она заведомо не получится потому что переключения тоннелей

Vort окей, попробую сказать почётче

Vort цель - не допустить разрастания очередей. разрастания очередей же дают неравномерность RTT, которую можно измерить

Vort но обрывы туннелей тоже дают неравномерность RTT

Vort я не представляю, как onon писал алгоритм, не решив этот принципиальный вопрос :/

orignal я тоже

orignal а лагать тоннели будут часто

orignal это данность

Vort то есть, выходит, с неравномерностью из-за очередей нам бороться надо, а с неравномерностью из-за переключений мы практически ничего не можем сделать

orignal именно так

orignal RTT будет все время скакать

Vort и нам надо понять, скачет он из-за очередей или из-за смены туннелей

orignal я бы сказал из-за размера окна

orignal *** отошел ***

Vort под очередью я понимаю ситуацию, когда набивается данных больше, чем физический канал в состоянии пропустить

Vort по алгоритмам CC: я думаю, нужно сделать детальное логирование для стримов у обеих версий, сделать по тесту для каждой из версий и запустить извлечение параметров работы алгоритма из этих данных

Vort нужны данные для определения скорости (или средней или максимальной - надо подумать), процентов перепосылок (или по количеству пакетов или по байтам) и равномерности RTT

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

Vort по скорости и перепосылкам можно получить число, по равномерности RTT для начала просто график вывести или гистограмму, может визуализация даст намёк на то, как посчитать численную оценку

orignal вторая версия это что?

Vort orignal: вторая - с тех ссылок, что onon скидывал несколько раз

Vort я имею в виду добавление логирование исключительно для целей тестирования

orignal ну понял. его версия

orignal не было времени глянуть

Vort кастомные логи - это самый удобный метод извлечения данных о стримах из i2pd

orignal так понятное дело

orignal просто некогда

Vort вот по такому принципу можно логи добавлять: github.com/Vort/i2pd/commit/f0ac512b72979223ffb58b44de81a54e76135a00

Vort ну да. а тут ещё китайцы опять повылазили

orignal а что с китайцами?

Vort ну вот это: "<~orignal> <dr|z3d> <zzz> about 3x the 0.9.58 routers we had on sat., from 6 to 18 % of net. China from maybe 1% to 10%"

Vort я хз что именно происходит, ко мне они не лезут

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

orignal так и я о том же

orignal не заметил каких то проблем

Vort в том то и суть

Vort сеть глючит, а почему - неясно

Vort это надо изучать, что именно эти узлы шлют

Vort но для начала надо иметь "вход" атаки на своём узле

orignal так я и спрашиваю

orignal как это проявляется

Vort рейт просаживается, туннели отваливаются

orignal так это и без китайцев было

Vort трафик в норме, транзиты в норме

Vort было то было, но когда приходят китайцы - ситуация становится в несколько раз хуже

Vort это чётко заметно

orignal тогда и правда надо понять что они делают

Vort скину сейчас для истории график с I2P Metrics

Vort paste.i2pd.xyz/?af8b7bdabb61da9e#6e7J1WkAibDV6hTabiKdj3heiy8fZe6DDSHhx5SoHx9c

orignal кстати я скажу почему рейт просаживается

orignal там же старые версии i2pd с тем багом

orignal кстати почему на графике там много иранских ослоебов?

колдырь orignal: про nullptr deref иссуй захлопни когда хочешь, других данных нет

orignal подождем

orignal я еще не смотрел

orignal короче я сделал гениальное открытие

orignal чем больше роутеров в нетдб тем ниже рейт ))

колдырь :)

колдырь закон жрандома-оригнала

orignal теорема целая ))

колдырь матстаты в принципе

колдырь недавно читал мульку о том что математики в массе херовато знают теорвер

` закон транзитофф - чем больше транзитофф тем меньше рейт

orignal потому что больше ротутеров

Anonymous orignal: you dropped your 10k limit!

Anonymous cake.i2p/file/fOTM0NBmAO_XSgFglsXIm7uzelbl28yCeCEGomAco_JehDDbHKkc/patch.diff

orignal where?

Vort "orignal чем больше роутеров в нетдб тем ниже рейт ))" ты ж уже уменьшал их количество более активной очисткой. и нихрена это рейт не подняло

Vort про иран обсуждали уже - хрен его знает откуда эти юзеры вообще взялись. я гуглил-гуглил, но так и не выгуглил

Vort "orignal там же старые версии i2pd с тем багом" где там? у китайцев?

Vort сомневаюсь, что ~700 узлов могут просадить рейт лишь старой версией, без каких-либо дополнительных воздействий на сеть

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

orignal Vort ну я просто заметил это

orignal на разных машинах счас пробовал

orignal да у китайцев

orignal дед говорил 0.9.56 и 0.9.58

Vort "<~orignal> Vort ну я просто заметил это" более общее описание эффекта - "у более нагруженных узлов обычно ниже рейт"

Vort к сожалению, это наблюдение само по себе мало что даёт

Vort так как непонятны причинно-следственные связи

orignal смотри

Vort ну и важное слово тут "обычно". может быть и наоборот

orignal запускал я роутер на ноуте с более тысячей узлов в netdb

orignal примерно неделю не запускал

orignal рейт был около 16%

orignal как только старые роутеры вычисстились через 11 минут сразу рейт подскочил до 30

orignal дело тут вот в чем

Vort вот у меня электричества не было 3 часа. рейт с ~15% поднялся до ~30%

orignal в нетдб роутеры не были говном мамонта но их было относительно много

orignal понимаешь неделю не запускал рейт 16%

orignal через 11 минут когда в нетдб их стало в 10 раз меньше рейт 30%

Vort несколько часов оффлайна достаточно, чтобы получить такой эффект

orignal да но у меня то эффект обратный

orignal неделя оффлайна рейт низкий

Vort а, ну понятно, слишком старые RI просаживали рейт поначалу

Vort но это понятное дело

Vort а вот почему оффлайн в несколько часов часто увеличивает рейт - загадка

Vort интродьюсеры протухают же примерно за час. может, в этом дело?

orignal так они не были слищком старые вот в чем дело

Vort но странно, что увеличенный рейт довольно долго держится

orignal неделя это не старые

Vort сутки - это уже старые

orignal именно поэтому у тебыя

orignal интродьюсеры протухли

orignal ты считаешь те роутеры недостижимыми

Vort по логике их опять дофига набиться должно, на флудфиле то

Vort но рейт держится

Vort я думаю, может быть ещё дело во входящих коннектах

Vort за час "прилипшие" узлы отлипают и наш узел уже набирает пиров "нейтрально"

Vort лучшего объяснения у меня пока что нету

Vort но, может, это всё фигня и в i2pd просто есть какой-то баг, который вылазит под нагрузкой

Anonymous > ~orignal │ where? < read the link diff file I gave, i2pd.conf comment xD

Anonymous )

Anonymous orignal: many new changes I see? congratulations

orignal I don't have time

Anonymous I made patch for you

Anonymous just `patch -p1<patch.diff`

orignal Vort ну так на том виндовом ноуте не было нагрузки

Vort загадочно

orignal мое объяснение что много роутеров которые в сети не постоянно

orignal в нетдю попали а реально их нет

Vort orignal: Anonymous говорит о том, что в документации надо дефолтные лимиты транзитов поправить. я тоже об этом говорил )

Vort orignal: ну это объяснение твоего эффекта с ноутом

orignal где именно ? на i2pd.readthedocs.io?

Vort а вот почему у меня рестарты или несколько часовой оффлайн повышает рейт - всё ещё непонятно

Vort orignal: в шаблоне конфига

orignal а без оффлана не повышают?

Anonymous Vort: EN pls

orignal это где такой?

Vort orignal: i2pd\contrib\i2pd.conf

orignal понял

Vort "<~orignal> а без оффлана не повышают?" - один рестарт - не особо повышает. рестарта три подряд - повышают побольше

Vort плюс после этих рестартов я вижу меньшую нагрузку на CPU

Vort явно какие-то "пассажиры" сбрасываются

Vort при рестартах, кстати, нету времени на протухание интродьюсеров

Vort так что, может, и не в этом дело. или не только в этом

orignal ну или при рестарте ты просто строишь тоннели все заново

orignal а не перестраиваешь старые

Vort перестраивание по логике должно давать выше рейт, а не ниже

Vort да и странно различие между первым рестартом и, допустим, третьим

Vort содержимое netdb тоже не должно сильно меняться между рестартами

Vort плохо, что сложно подтверждать такие эффекты

Vort они воспроизводятся ненадёжно

Vort я наблюдал эффект когда тестировал разные изменения в коде

Vort обычно рестартну, минут 10 потестирую, увижу баг, исправлю, опять рестарт

Vort и вот так всё больше и больше нагрузки сбрасывалось с каждым рестартом

orignal перестаривание видимо дает ниже рейт потому что при повтороном там уже узел перегружен и идет отлуп

Anonymous orignal: fix your code

Anonymous cake.i2p/file/HTRa6EzgqL_4zUHjMLxRsDKz0OIklR2D8RTWLJzIp_MSb17JPO9o/better-formatting.diff

Anonymous Vort: don't you agree?

orignal отстань я занят

Anonymous SSU2.cpp is 246 lines LESS and more readable, especially on a smaller screen

Anonymous was 1507 SLOC, now 1261 SLOC

Vort Anonymous: code style is highly controversial topic. it is better to do something more useful

Anonymous If I applied this to all i2pd code which is ~42000 (wc -l), it would be more like 35112 SLOC not 42000 SLOC

Anonymous Vort: it is not, I find i2pd code unreadable

Anonymous why do you think orignal fixes useless bugs?

Anonymous I read commit messages

Anonymous The code is funny

Anonymous Code mistakes I mean

Anonymous To a professional programmer, that's a lot of mistakes

orignal mistakes?

Anonymous And I'd make them too because I see it as unreadable

Anonymous yes

Anonymous you fix your mistakes

orignal there is no mistakes in the code

Anonymous but they're tiny mistakes and there's a lot of them

Anonymous meaning lots of little tiny bugs

Vort orignal: короч ему хочется скобочки в коде двигать

Anonymous reduce lines of code = smaller attack surface = less bugs

orignal otherwise compiler would produce an error message

orignal Vort ну я так и понял

Anonymous orignal: if you think that an compiler can see your non-logical mistakes for you then we are all deanon and i2pd is fake

Anonymous Vort: how much do I have to pay for orignal to learn EN? ))

orignal please give me an expample of logic mistake

orignal in my code

Anonymous I said non-logical

Anonymous Just because compiler says it's ok doesn't mean it's ok

Anonymous orignal: I think the more code we see all at once, the less we have to trust our brain memory to memorize

Anonymous orignal: I'm curious, what is your tabstop for text editor?

orignal 4

Anonymous exactly

Anonymous I started with 8

Anonymous gone to 4

Anonymous gone 2

Anonymous 2 feels best: most code can fit and you see like 50% more code xD

Anonymous our brains are stupid, so we have to use brain less

Anonymous fit more code in small area of eye vision = less brain you have to use

Anonymous > where is my fucking uint16_t mtu variable? fuck can't find it

Anonymous save on newlines like { and maybe you see it better, example

Anonymous it worked for me, it could work for you ))

Anonymous and I have dyslexia probably, orignal, so that's saying a lot

Anonymous It's like 16% less code on average

Anonymous that's a lot more readable

Anonymous (depends how many { newlines you have and stuff)

Anonymous Wait when I fix my eyes, we bring 42k SLOC to 35k SLOC to 30k SLOC, much less bugs

Anonymous you see

Anonymous orignal: it will be weird to work with tabstop=2 and smaller SLOC like my diff, but you'll see it's better after 3 days of work with it like that

Anonymous This is my contribution, don't take it lightly, people have written operating systems with this in mind and we run them everyday (Unix philosophy)

Anonymous suckless.org/coding_style

Anonymous orignal: st is ~6k SLOC. xterm is 65k SLOC. rxvt is 32k SLOC st.suckless.org

Anonymous Who do you think will have more bugs?

Anonymous Я знаю, ты хочешь, чтобы я ушла, но я хочу помочь тебе сделать меньше ошибок, твой код воняет и ты не знаешь, как писать код!

orignal are you female? )))

Anonymous Вы совершаете 50 ошибок и исправляете 50 ошибок и чувствуете усталость и радость, вы сделали так много исправлений. Лучше 35 ошибок, чем 50!

Anonymous_ > ~orignal │ please give me an expample of logic mistake <

Anonymous_ giteabolfdejtdzblkooalqei6jr67imiugmhtsh6ocw4hlj5a4q.b32.i2p/PurpleI2P/i2pd/commits/branch/openssl

Anonymous_ here it is, if you consider a bad programming style a bad logical decision ))

Anonymous_ # of commits doesn't matter, how many mistakes you make matters

Anonymous_ Especially because many many people use i2pd

Anonymous_ Making stupid mistakes makes me think you make them on purpose to deanon users, orignal

Anonymous_ anyways nice changelog yay

Anonymous_ orignal: if you haven't already, take a look at "block diagrams" or "flowcharts", it can be text-mode or an image.

Anonymous_ What it does is ease off your brain, and remind you how everything works

Anonymous_ Humans learn best visually-wise.

Anonymous_ Books are great, but movies/visual media (eye-seeing) is best for learning and learning fast

Anonymous_ Want more good developers on i2pd?

Anonymous_ Learn English and flowcharts can help you too, not just new developers

Anonymous_ libtorrent does this

Anonymous_ libtorrent.org/img/hacking.png

Anonymous_ this is what I mean, orignal. can be image, can be text

Anonymous_ it helps you

Anonymous_ it makes it easy to understand i2pd and it's code and new devs come and help you, i2pd and everyone

orignal исчезни

orignal клоун блять

Anonymous_ Полиция под угрозой, компромисс - это ты!