Regarding thain-ipv8, this has all the hallmarks of being the product of
a very short llm prompt. This is tedious and a waste of everyones' time.
там уже выкачен -01, в диффе четные-нечетные адреса:
1.4. Zone Server Redundancy and Even/Odd Addressing
Every IPv8 network segment operates with two Zone Servers, assigned
the two highest addresses in the subnet: .254 (even) and .253 (odd).
These are the two default gateways issued to every device in the
DHCP8 lease response.
IPv8 traffic follows an even/odd affinity model: even-addressed hosts
route via the even Zone Server (.254) and odd-addressed hosts route
via the odd Zone Server (.253). Each Zone Server is the PVRST root
for its respective VLANs. Under normal operation the load is
distributed across both Zone Servers with no single point of failure.
On Zone Server failure, traffic fails over to the surviving gateway
automatically.
Hosts SHOULD be assigned addresses matching their primary traffic
path. Dual-NIC hosts SHOULD be issued one even and one odd address
by DHCP8 -- one per NIC -- enabling full simultaneous use of both
gateway paths and both physical links. Full redundancy is achieved
with no additional configuration: loss of either NIC or either Zone
Server results in automatic failover on the surviving path.
Administrators MAY deviate from even/odd assignment where operational
requirements justify it.
ну это точно ИИ-дичь, в реале такое нежизнеспособно
Нет, это отвратительное инженерное решение. Тридцать лет назад и то понимали, что нельзя просто взять и оставить заголовок IPv4 как есть, кроме адресов. А этот JSON Web Token так вообще ужас.
Описанные вещи в статье на самом деле давно известны, это “отчуждение труда” - просто обычно не понимают, что это словосочетание значит. Когда результат лишь цифры, когда материально пощупать - это вот оно всё про это. Хорошо тема раскрыта в серии постов http://lex-kravetski.livejournal.com/305198.html - ну и, понятное дело, если подробно знать что это, как и почему, можно суметь и даже с чисто кодом все равно получать эту обратную связь и пр.
Если быть честным, за 30+ лет конкретно в Вебе “развития технологий” наблюдалось не особо. Даже вех-то не особо много, что там, изобретение JS? Переход от модели Apache/CGI к модели nginx/FastCGI? Замена XML на JSON? И несмотря на всё это, он продолжает быть столь же архитектурно корявым, как 30 лет назад - БД на бэкенде, cookie - и столь же убогим практически: вот только недавно у кого-то прочитал навроде, что сделать таблицу на десять тыщ строк на реакте, и оно будет люто тормозить и сломается под собственным весом, в противовес какому-нибудь Excel (да, и 30 лет назад было аналогично). Лично мне Веб перестал быть интересен где-то между 2006 и 2011, когда я сделал сайт с шаблонизатором и потом FastCGI, дальше ничего фундаментально нового не появлялось (ну заменили стадию подстановки структуры данных, эквивалентной JSON, на стадии генерации HTML на бэкенде шаблонизатором, на этот самый JSON и рендеринг шаблона в single page прям на клиенте, ничего кардинального, те же яйца, вид сбоку, разве что тормозить больше стало). Даже вебсокеты были сделаны коряво и не смогли переломить архитектуру от “запрос-ответ” к нормальным постоянным TCP-соединениям, вполне типовым уже к началу 90-х (рождению веба).
Чтобы его не проверять регулярно, применили подход с бутстрапом: достаточно маленький компилятор, кажется пять тыщ строк на Scheme, собирает основной компилятор*, и бинарь того таким образом можно считать доверенным.
*Точнее, там mutual и полная цепь длиннее как до, так и после: GNU Mes состоит из маленького компилятора Си на схеме и маленького интерпретатора схемы на Си. Ими дальше собирается другой компилятор Си помощнее, способный скомпилировать старый GCC, а тем уже в итоге нормальный. А начинается всё с маленького платформенного ассемблера.
Это всё решается нормальным роутингом, когда на российские IP идём напрямую, без VPN. Еще и работать будет чуть быстрее и меньше зарубежного трафика потратит.
Нет, тут не сугубо желтое, а вообще всё целиком. Нет, я не знаю, каким образом они сумели скомбинировать вот эту фамильярность с этой суммаризацией нумерированных поинтов. Возможно, какой-то bias в разметке входных данных, но люди всё-таки обычно не выражаются помесью Шелдона с бухим тамадой.
Нормальный заголовок и нормальная терминология - автор рассматривает системное явление, а не исключения “от нормальных людей” (если кажется, что в айти для “исключений” слишком многовато, просто посмотрите на другие отрасли).
Ну congestion control тут, конечно, адовый. И дело даже не в том, что этот Brutal создает легко различимый паттерн для блокировщиков - он, блджад, всем остальным рядом мешает! Причем в том числе и провайдеру, поэтому они постараются заблочить такое даже без всяких РКН-ов. История 2010 года с muTP (из muTorrent) ничему не научила людей - те тоже попытались в congestion control уменьшением размера пакетов, не соображая, что оборудованию плохеет не от байтов в секунду, а от пакетов в секунду. Так что их тогда начали пытаться блокировать сами провайдеры, еще до всяких РКН-ов.
Вот если бы эти ребята изобрели способ отличать потери пакетов из-за congestion от потерь самой сети (спутника например) или шейпера на 30% - им бы премию дали и на руках в IETF носили. Напомню, собственно congestion control появился в конце 80-х как раз из-за того, что Интернет оказался дичайше перегружен, всё лагало и мало что открывалось: на каком-то линке потерялся пакет из-за забитости, его TCP отправителя начинает ретрансмитить, еще более увеличивая количество пакетов в сети, начинают теряться другие пакеты, в т.ч. других соединений, их TCP тоже начинают ретрансмиты, и так каскадно. Это назвали тогда Internet meltdown - по аналогии с расплавлением активной зоны реакторы из фильма “Китайский синдром”.
Они могут делать это в оффлайне, в принципе. То есть, трафик, который не классифицирован четко как что-то легитимное, по превышению трешолдов объема/длительности становится кандидатом на анализ, из кандидатов сэмплингом (скажем 1 из 4000) выбираются случайные flow и отправляются pcap-ом на оффлайн-анализатор с ML. Таким образом, пусть медленно, пусть с задержкой, но статистически самые популярные подозреваемые могут быть пойманы - а, понятное дело, если на таком-то IP сидит массовый VPN сегодня, он скорее всего будет сидеть там же и через месяц. Массовые же и интересуют прежде всего, за 100% эффективнностью не гонятся.
Обход был очевиден еще и до ML-тем - не быть популярным, так как наибольшее внимание уделяют самым популярным методам. В разнообразии наша сила :)
Хотел было написать комментарий с разбором этого тоталитаризма, а потом присмотрелся…
https://mailarchive.ietf.org/arch/msg/ietf/w1Qn9HEukA6n3IuF2zbUeDJvYOM/ :
https://mailarchive.ietf.org/arch/msg/ietf/LpXuQS23JweC853UMpL7nFSBzsE/ :
там уже выкачен -01, в диффе четные-нечетные адреса:
ну это точно ИИ-дичь, в реале такое нежизнеспособно
Нет, это отвратительное инженерное решение. Тридцать лет назад и то понимали, что нельзя просто взять и оставить заголовок IPv4 как есть, кроме адресов. А этот JSON Web Token так вообще ужас.
Два раза дату перепроверил - не первое апреля.
Описанные вещи в статье на самом деле давно известны, это “отчуждение труда” - просто обычно не понимают, что это словосочетание значит. Когда результат лишь цифры, когда материально пощупать - это вот оно всё про это. Хорошо тема раскрыта в серии постов http://lex-kravetski.livejournal.com/305198.html - ну и, понятное дело, если подробно знать что это, как и почему, можно суметь и даже с чисто кодом все равно получать эту обратную связь и пр.
Всё просто: когда нейронка выше уровнем пользующегося, дофамин будет, а когда ниже, то наоборот.
Если быть честным, за 30+ лет конкретно в Вебе “развития технологий” наблюдалось не особо. Даже вех-то не особо много, что там, изобретение JS? Переход от модели Apache/CGI к модели nginx/FastCGI? Замена XML на JSON? И несмотря на всё это, он продолжает быть столь же архитектурно корявым, как 30 лет назад - БД на бэкенде, cookie - и столь же убогим практически: вот только недавно у кого-то прочитал навроде, что сделать таблицу на десять тыщ строк на реакте, и оно будет люто тормозить и сломается под собственным весом, в противовес какому-нибудь Excel (да, и 30 лет назад было аналогично). Лично мне Веб перестал быть интересен где-то между 2006 и 2011, когда я сделал сайт с шаблонизатором и потом FastCGI, дальше ничего фундаментально нового не появлялось (ну заменили стадию подстановки структуры данных, эквивалентной JSON, на стадии генерации HTML на бэкенде шаблонизатором, на этот самый JSON и рендеринг шаблона в single page прям на клиенте, ничего кардинального, те же яйца, вид сбоку, разве что тормозить больше стало). Даже вебсокеты были сделаны коряво и не смогли переломить архитектуру от “запрос-ответ” к нормальным постоянным TCP-соединениям, вполне типовым уже к началу 90-х (рождению веба).
Ну, попробуйте развиться куда-то выше “задач от работодателя”. Помыслить про прогресс, например.
Чтобы его не проверять регулярно, применили подход с бутстрапом: достаточно маленький компилятор, кажется пять тыщ строк на Scheme, собирает основной компилятор*, и бинарь того таким образом можно считать доверенным.
*Точнее, там mutual и полная цепь длиннее как до, так и после: GNU Mes состоит из маленького компилятора Си на схеме и маленького интерпретатора схемы на Си. Ими дальше собирается другой компилятор Си помощнее, способный скомпилировать старый GCC, а тем уже в итоге нормальный. А начинается всё с маленького платформенного ассемблера.
Порносайты стали делать свой софт для телефонов?
Это всё решается нормальным роутингом, когда на российские IP идём напрямую, без VPN. Еще и работать будет чуть быстрее и меньше зарубежного трафика потратит.
И зачем тогда нужен потенциальный троян?
Ох, опять этот поехавший школьник ElonMusk (еще и “мы”) рекламирует свой AsmX, который, судя по roadmap, опять ничего реального не может.
Оплата картой решает одну очень простую, поэтому well-defined, функцию. В рассматриваемой же области такого принципиально нет.
Нет, тут не сугубо желтое, а вообще всё целиком. Нет, я не знаю, каким образом они сумели скомбинировать вот эту фамильярность с этой суммаризацией нумерированных поинтов. Возможно, какой-то bias в разметке входных данных, но люди всё-таки обычно не выражаются помесью Шелдона с бухим тамадой.
Нет, не пишут. На скриншоте пример того, как живой человек практически наверняка писать не будет, а вот для нейронок этот стиль очень характерен.
Сравнивать RedHat с Астрой очень смешно. Редхат таки да, производит софт, а не “перепаковывает с патчами”.
Нормальный заголовок и нормальная терминология - автор рассматривает системное явление, а не исключения “от нормальных людей” (если кажется, что в айти для “исключений” слишком многовато, просто посмотрите на другие отрасли).
Ну congestion control тут, конечно, адовый. И дело даже не в том, что этот Brutal создает легко различимый паттерн для блокировщиков - он, блджад, всем остальным рядом мешает! Причем в том числе и провайдеру, поэтому они постараются заблочить такое даже без всяких РКН-ов. История 2010 года с muTP (из muTorrent) ничему не научила людей - те тоже попытались в congestion control уменьшением размера пакетов, не соображая, что оборудованию плохеет не от байтов в секунду, а от пакетов в секунду. Так что их тогда начали пытаться блокировать сами провайдеры, еще до всяких РКН-ов.
Вот если бы эти ребята изобрели способ отличать потери пакетов из-за congestion от потерь самой сети (спутника например) или шейпера на 30% - им бы премию дали и на руках в IETF носили. Напомню, собственно congestion control появился в конце 80-х как раз из-за того, что Интернет оказался дичайше перегружен, всё лагало и мало что открывалось: на каком-то линке потерялся пакет из-за забитости, его TCP отправителя начинает ретрансмитить, еще более увеличивая количество пакетов в сети, начинают теряться другие пакеты, в т.ч. других соединений, их TCP тоже начинают ретрансмиты, и так каскадно. Это назвали тогда Internet meltdown - по аналогии с расплавлением активной зоны реакторы из фильма “Китайский синдром”.
Они могут делать это в оффлайне, в принципе. То есть, трафик, который не классифицирован четко как что-то легитимное, по превышению трешолдов объема/длительности становится кандидатом на анализ, из кандидатов сэмплингом (скажем 1 из 4000) выбираются случайные flow и отправляются pcap-ом на оффлайн-анализатор с ML. Таким образом, пусть медленно, пусть с задержкой, но статистически самые популярные подозреваемые могут быть пойманы - а, понятное дело, если на таком-то IP сидит массовый VPN сегодня, он скорее всего будет сидеть там же и через месяц. Массовые же и интересуют прежде всего, за 100% эффективнностью не гонятся.
Обход был очевиден еще и до ML-тем - не быть популярным, так как наибольшее внимание уделяют самым популярным методам. В разнообразии наша сила :)
Правильно, для таких условий должны быть свои Application-протоколы, а не TCP туннелировать. Телеграм однажды умрёт, и мы ему поможем.