С одной стороны, это не совсем так — баллы однозначно выводятся из решённых задач, причем правила известны заранее (пример).
С другой, составители экзамена по математике стараются поддерживать какое-то распределение результатов — чтобы и количество стобалльников не росло, и сложность экзамена не была запредельной. Поскольку как-либо влиять на экзамен текущего года нельзя, то все корректировки происходят в экзаменах следующего года по результатам прошедшего. Это приводит к тому, что сложность ЕГЭ от года к году немного колеблется туда-сюда.
Это хорошо видно по проходным баллам на бюджет (которые как раз используют скорее рейтинговую систему)
Последние годы картина могла несколько смазаться из-за резкого увеличения конкурса на место по независящим от ЕГЭ причинам, но в целом колебания сохраняются.
Сравнение в абсолютных миллисекундах без одинакового железа и одинакового входного материала ограниченно. Нормальный следующий шаг, прогнать EVRTCK, H.264 H.265/AV1 и VNC на одних и тех же desktop traces и сравнить не только encode time, но и итоговый трафик, latency, CPU/GPU load и поведение при разных dirty-area.
Да-да, LLM тут вам прям по делу советует. Если бы вы приложили эти числа, то статья бы стала заметно интереснее. А если бы вы ещё и объяснили как работают ваши чудо-алгоритмы и почему именно они оказываются лучше AV1, то вообще огонь.
С VNC сравнение интересно, потому что задача действительно близкая: для обычного декстоп-контента там тоже давно используются region-based оптимизации.
Да, я ровно это и написал в комментарии выше. Радует, что LLM более развернуто раскрыла мою мысль, спасибо.
Его сильная сторона — low-entropy desktop: текст, курсор, окна, небольшие redraw'ы.
Сильные стороны это здорово, но сильнее ли оно AV1? Из того что я понял из статьи и ваших комментариев — у решения есть сильная сторона (low-entropy desktop), где он на уровне AV1 или хуже (по ~3мс на кадр) и есть слабая сторона (игры), где он сильно хуже. Это, конечно, неплохо, но почему не AV1-то?
каждый раз прогонять его через обычный video pipeline.
Я тут ну прям совсем не эксперт, но какие-то эксперименты с GPU ставил и даже курс какой проходил. Есть чувство, что тратить ресурсы CPU и гонять сырое изображение по PCI шине это хуже, чем гонять сжатые байты на GPU и уже там декодировать изображение используя ресурсы специального куска кремния. Если это не так, то интересно в каких сценариях и почему.
Интереснее вся система целиком, сколько данных реально ушло, когда обновление оказалось у клиента и сколько ресурсов пришлось для этого потратить.
Тут опять дело написано. Действительно, было бы интересно увидеть рассказ о системе в целом и как именно она оказывается лучше более банальных решений (и насколько). Особенно когда рядом есть аппаратный AV1-декодер. Ну или хотя бы H264, который кажется сейчас в каждом чайнике.
Я как раз открыл исходники именно затем, чтобы это можно было проверить независимо от моих слов.
По правде признаться, я вам тут и на слово поверю. Вы просто скажите — лучше ли оно аппаратного AV1 и насколько? Я в статье не увидел ваших проверок и чисел.
Если мои цифры не воспроизводятся - это тоже будет полезный результат.
Так вы же сами в самом начале сказали, что без одинакового железа и одинакового входного материала сравнение ограничено. Как же я тогда воспроизведу ваши цифры?
Измерения в абсолютных единицах сами по себе несут мало смысла. Уж очень они разнятся от конкретной картинки и конкретной машины. Здесь интересно сравнить относительно с H264/H265/AV1 в процентах.
Например, 3мс encode меня не очень впечатляет. У меня примерно столько же занимает кодирование AV1 в разрешении ближе к 4К (против ваших 1920x1440) для игр в VR. И это почти бесплатно, поскольку нынче в GPU почти всегда есть аппаратный энкодер видео, который обычно простаивает.
Если же вы хотите сосредоточится на оптимизации под сценарии работы с десктопом, то стоит сравнить ваш протокол с старичком VNC. Там как раз есть различные оптимизации в эту же сторону.
Часть проекта открыта: SDK опубликован на GitHub, и код протокола обфускации и decoy‑логики можно посмотреть непосредственно в реализации, а не только в пересказе статьи.
А где опубликован-то? В статье нет ни ссылки, ни названия проекта.
Для этой уязвимости достаточно отправить серию специально сфабрикованных HTTP-запросов в nginx с уязвимой конфигураций.
Причем запросы не являются особенно необычными — они спокойно проходят через reverse proxy над уязвимым nginx и с хорошей вероятностью переживают различного рода rewrite. Поэтому, по-умолчанию следует предполагать, что даже в самом внутреннем вашем nginx эту уязвимость можно эксплуатировать извне, если атакующий хотя бы частично контролирует URL.
Сама уязвимая конфигурация nginx не то что бы сильно странная — нужна комбинация директив rewrite с знаком вопроса и set. Но определенно и не очень популярная. Какие-то свои задачи такой паттерн решает, и лично я даже могу вспомнить когда писал ровно такую конструкцию.
От дыры в какой-то мере защищает ASLR, но при должном терпении и его тоже можно обойти. В публичных эксплойтах его обхода (пока?) не было. Здесь владельцам nginx имеет смысл смотреть на всплески крешей worker-процессов — это почти неизбежный сайд-эффект от попытки эксплуатации.
А в чем дыра? MCP-сервер естественным образом может исполнять произвольный код там, где он запущен — в этом практически и есть суть MCP-серверов. Это ничем не отличается от магазина расширений VSCode, сборочных скриптов в npm (и многих других системах сборки), установки программ на компьютер.
Задача компании: модерировать контент, чтобы соответствовать требованиям законодательства и продолжать существование.
Если делать MTProxy / SOCKS / whatever и никак не модифицировать трафик между клиентом и телеграмом, а всю модерацию делать в клиенте, то поверх этого удобного туннеля появятся сторонние клиенты, которые не соответствуют законодательству. Где-то в этот момент ООО Телега начинает представлять средства обхода блокировок и быстро перестает существовать.
Следовательно, модерация должна быть на сервере с MITM. Если делать свой наколеночный REST / RPC / whatever вместо MTProto, то его придется делать (очевидно) и переводить на него весь клиент телеги. Видимо, тут банально оказалась дешевле оставить MTProto в качестве RPC и один раз реализовать весь стек шифрования вместо рефакторинга клиентов под все платформы. Тем более, что у этого протокола даже есть документация (пусть и скудная), чего нельзя сказать об исходниках официальных клиентов.
Мне когда-то давно карту яндекс.денег отправляли почтой — просто болванка в конверте до момента активации. Непонятно, почему озон/яндекс/WB не начинают аналогично отправлять карты на маркетплейсах. Чай уж логистика у них уже выстроена — можно хоть курьером на дом, хоть в один из тысяч ПВЗ.
На самом деле, я ещё не видел дистрибутивов линукса, которые в своей дефолтной инсталляции тащат с собой rustc. Да что уж там, хватает дистрибутивов, которые и gcc/clang не приносят. Так что наличие/отсутствие rustc не является показателем использования Rust в ядре или в стандартных утилитах
Секреты проприетарных кодеков только при кодировании видео. При декодировании сложно изобрести что-то новое — для любого декодера из одних сжатых данных всегда должна получаться одна и та же картинка. Можно разве что производительность тюнить — но всё равно массово AV2-контент появится только с распространением нативной поддержки в железе.
Разрабатывать новое важно и нужно только в тех случаях, когда существующие инструменты вашу задачу не решают или решают её плохо.
Тот же MTProto, например, появился до того как gRPC стал популярен, поэтому его появление было довольно неизбежно — у разработчиков тг не имелось на руках эффективного бинарного протокола.
Но сейчас, например, телеграм всё никак не может дотащить звонки в веб-версию, поэтому что webrtc примерно никак не укладывается в их стек и их шифрование.
Владелец железа запускает у себя воркер — специальную виртуалку, которая изолирована с помощью Intel TDX.
tar с моделью монтируется с хоста в воркер, здесь воркер использует свой доверенный dm-verity, чтобы защитить архив от модификации. Хеш архива анонсируется в сеть.
Клиент использует хеш нужной ему модели, чтобы найти воркер в сети. Потом он верифицирует, что виртуалка действительно внутри Intel TDX и её содержимое не было скомпрометировано.
После аттестации между клиентом и воркером есть TLS-соединение, в котором они обмениваются задачей и результатом.
Воркер использует GPU, чтобы сделать вычисления. Здесь используется NVidia CC, чтобы воркер мог верифицировать, что у него реальная железная GPU, а не что-то фейковое. Клиент аттестацию GPU не проверяет, но он уже аттестовал виртуалку с воркером.
И ещё между клиентом и воркером есть прокси, которые обеспечивают всем участникам справедливые выплаты. Там какая-то жесть с смарт-контрактами, я уже не копал.
Итого: клиент находит подходящий воркер по хешу модели, он не может попросить кого-то выполнить нужную ему модель. Но сама модель на воркерах может быть совершенно любой, хоть проприетарной— клиентам виден только её хеш.
Как человек, однажды год фуллтайм работавший с другим "собственным бинарным протоколом, разработанном с нуля, с встроенным шифрованием и ещё что-то" (*), очень вас прошу — не надо. Я этим уже не занимаюсь, но продолжаю от коллег слышать только плохое и нисколько хорошего.
Мы живём в прекрасное время, когда уже существует https, умееющий в авторизацию по клиентскому сертификату. Уже есть http2 с долгими сессиями и server push. Наконец, уже есть grpc, который всё это красиво оборачивает. Сегодня примерно любая задача передачи данных между двумя акторами эффективно решается широко распространенными инструментами. Изобретать новые почти точно не стоит.
Собственно, сейчас при желании нет никаких проблем почитать устройство TString, ибо его тащат на гитхаб примерно все опенсорсгые проекты Яндекса (YT, YDB): тык
DeepMind занимался машинным обучением ещё до бума LLM, который сейчас все называют ИИ, и активно продолжает заниматься им и сейчас. Собственно, в этой статье никакой ИИ (LLM) никуда не суют, речи про AGI и близко не идёт, а вместо этого используют вполне привычное машинное обучение для того, чтобы аппроксимировать поведение диффуров и находить скрытые закономерности.
Из блога DeepMind
Our approach is based on the use of Physics-Informed Neural Networks (PINNs). Unlike conventional neural networks that learn from vast datasets, we trained our models to match equations which model the laws of physics. The network's output is constantly checked against what the physical equations expect, and it learns by minimizing its ‘residual’, the amount by which its solution fails to satisfy the equations.
Our use of PINNs goes beyond their typical role as general-purpose tools used for solving partial differential equations (PDEs). By embedding mathematical insights directly into the training, we were able to capture elusive solutions — such as unstable singularities — that have long-challenged conventional methods.
Но на сегодняшний день AI продает лучше чем Machine Learning, вот и суют куда попало.
С одной стороны, это не совсем так — баллы однозначно выводятся из решённых задач, причем правила известны заранее (пример).
С другой, составители экзамена по математике стараются поддерживать какое-то распределение результатов — чтобы и количество стобалльников не росло, и сложность экзамена не была запредельной. Поскольку как-либо влиять на экзамен текущего года нельзя, то все корректировки происходят в экзаменах следующего года по результатам прошедшего. Это приводит к тому, что сложность ЕГЭ от года к году немного колеблется туда-сюда.
Это хорошо видно по проходным баллам на бюджет (которые как раз используют скорее рейтинговую систему)
Графики
Последние годы картина могла несколько смазаться из-за резкого увеличения конкурса на место по независящим от ЕГЭ причинам, но в целом колебания сохраняются.
Да-да, LLM тут вам прям по делу советует. Если бы вы приложили эти числа, то статья бы стала заметно интереснее. А если бы вы ещё и объяснили как работают ваши чудо-алгоритмы и почему именно они оказываются лучше AV1, то вообще огонь.
Да, я ровно это и написал в комментарии выше. Радует, что LLM более развернуто раскрыла мою мысль, спасибо.
Сильные стороны это здорово, но сильнее ли оно AV1? Из того что я понял из статьи и ваших комментариев — у решения есть сильная сторона (low-entropy desktop), где он на уровне AV1 или хуже (по ~3мс на кадр) и есть слабая сторона (игры), где он сильно хуже. Это, конечно, неплохо, но почему не AV1-то?
Я тут ну прям совсем не эксперт, но какие-то эксперименты с GPU ставил и даже курс какой проходил. Есть чувство, что тратить ресурсы CPU и гонять сырое изображение по PCI шине это хуже, чем гонять сжатые байты на GPU и уже там декодировать изображение используя ресурсы специального куска кремния. Если это не так, то интересно в каких сценариях и почему.
Тут опять дело написано. Действительно, было бы интересно увидеть рассказ о системе в целом и как именно она оказывается лучше более банальных решений (и насколько). Особенно когда рядом есть аппаратный AV1-декодер. Ну или хотя бы H264, который кажется сейчас в каждом чайнике.
По правде признаться, я вам тут и на слово поверю. Вы просто скажите — лучше ли оно аппаратного AV1 и насколько? Я в статье не увидел ваших проверок и чисел.
Так вы же сами в самом начале сказали, что без одинакового железа и одинакового входного материала сравнение ограничено. Как же я тогда воспроизведу ваши цифры?
Измерения в абсолютных единицах сами по себе несут мало смысла. Уж очень они разнятся от конкретной картинки и конкретной машины. Здесь интересно сравнить относительно с H264/H265/AV1 в процентах.
Например, 3мс encode меня не очень впечатляет. У меня примерно столько же занимает кодирование AV1 в разрешении ближе к 4К (против ваших 1920x1440) для игр в VR. И это почти бесплатно, поскольку нынче в GPU почти всегда есть аппаратный энкодер видео, который обычно простаивает.
Если же вы хотите сосредоточится на оптимизации под сценарии работы с десктопом, то стоит сравнить ваш протокол с старичком VNC. Там как раз есть различные оптимизации в эту же сторону.
А где опубликован-то? В статье нет ни ссылки, ни названия проекта.
Не переживайте, гугл работает и над этим: Верификация Android разработчиков:
Ну это в stable нет =)
https://doc.rust-lang.org/nightly/std/random/fn.random.html
Для этой уязвимости достаточно отправить серию специально сфабрикованных HTTP-запросов в nginx с уязвимой конфигураций.
Причем запросы не являются особенно необычными — они спокойно проходят через reverse proxy над уязвимым nginx и с хорошей вероятностью переживают различного рода rewrite. Поэтому, по-умолчанию следует предполагать, что даже в самом внутреннем вашем nginx эту уязвимость можно эксплуатировать извне, если атакующий хотя бы частично контролирует URL.
Сама уязвимая конфигурация nginx не то что бы сильно странная — нужна комбинация директив rewrite с знаком вопроса и set. Но определенно и не очень популярная. Какие-то свои задачи такой паттерн решает, и лично я даже могу вспомнить когда писал ровно такую конструкцию.
От дыры в какой-то мере защищает ASLR, но при должном терпении и его тоже можно обойти. В публичных эксплойтах его обхода (пока?) не было. Здесь владельцам nginx имеет смысл смотреть на всплески крешей worker-процессов — это почти неизбежный сайд-эффект от попытки эксплуатации.
А в чем дыра? MCP-сервер естественным образом может исполнять произвольный код там, где он запущен — в этом практически и есть суть MCP-серверов. Это ничем не отличается от магазина расширений VSCode, сборочных скриптов в npm (и многих других системах сборки), установки программ на компьютер.
Задача компании: модерировать контент, чтобы соответствовать требованиям законодательства и продолжать существование.
Если делать MTProxy / SOCKS / whatever и никак не модифицировать трафик между клиентом и телеграмом, а всю модерацию делать в клиенте, то поверх этого удобного туннеля появятся сторонние клиенты, которые не соответствуют законодательству. Где-то в этот момент ООО Телега начинает представлять средства обхода блокировок и быстро перестает существовать.
Следовательно, модерация должна быть на сервере с MITM. Если делать свой наколеночный REST / RPC / whatever вместо MTProto, то его придется делать (очевидно) и переводить на него весь клиент телеги. Видимо, тут банально оказалась дешевле оставить MTProto в качестве RPC и один раз реализовать весь стек шифрования вместо рефакторинга клиентов под все платформы. Тем более, что у этого протокола даже есть документация (пусть и скудная), чего нельзя сказать об исходниках официальных клиентов.
Тут необходимо использовать механизм Takeout, чтобы не втыкаться так сильно в рейтлимиты: https://docs.telethon.dev/en/stable/modules/client.html#telethon.client.account.AccountMethods.takeout
Мне когда-то давно карту яндекс.денег отправляли почтой — просто болванка в конверте до момента активации. Непонятно, почему озон/яндекс/WB не начинают аналогично отправлять карты на маркетплейсах. Чай уж логистика у них уже выстроена — можно хоть курьером на дом, хоть в один из тысяч ПВЗ.
На самом деле, я ещё не видел дистрибутивов линукса, которые в своей дефолтной инсталляции тащат с собой rustc. Да что уж там, хватает дистрибутивов, которые и gcc/clang не приносят. Так что наличие/отсутствие rustc не является показателем использования Rust в ядре или в стандартных утилитах
Это же сколько алюминия уходит на память, что его не хватает на радиаторы.
«Промптхаб — давайте делать всё с нейросетями»
Секреты проприетарных кодеков только при кодировании видео. При декодировании сложно изобрести что-то новое — для любого декодера из одних сжатых данных всегда должна получаться одна и та же картинка. Можно разве что производительность тюнить — но всё равно массово AV2-контент появится только с распространением нативной поддержки в железе.
Разрабатывать новое важно и нужно только в тех случаях, когда существующие инструменты вашу задачу не решают или решают её плохо.
Тот же MTProto, например, появился до того как gRPC стал популярен, поэтому его появление было довольно неизбежно — у разработчиков тг не имелось на руках эффективного бинарного протокола.
Но сейчас, например, телеграм всё никак не может дотащить звонки в веб-версию, поэтому что webrtc примерно никак не укладывается в их стек и их шифрование.
Там такая цепочка:
Владелец железа запускает у себя воркер — специальную виртуалку, которая изолирована с помощью Intel TDX.
tar с моделью монтируется с хоста в воркер, здесь воркер использует свой доверенный dm-verity, чтобы защитить архив от модификации. Хеш архива анонсируется в сеть.
Клиент использует хеш нужной ему модели, чтобы найти воркер в сети. Потом он верифицирует, что виртуалка действительно внутри Intel TDX и её содержимое не было скомпрометировано.
После аттестации между клиентом и воркером есть TLS-соединение, в котором они обмениваются задачей и результатом.
Воркер использует GPU, чтобы сделать вычисления. Здесь используется NVidia CC, чтобы воркер мог верифицировать, что у него реальная железная GPU, а не что-то фейковое. Клиент аттестацию GPU не проверяет, но он уже аттестовал виртуалку с воркером.
И ещё между клиентом и воркером есть прокси, которые обеспечивают всем участникам справедливые выплаты. Там какая-то жесть с смарт-контрактами, я уже не копал.
Итого: клиент находит подходящий воркер по хешу модели, он не может попросить кого-то выполнить нужную ему модель. Но сама модель на воркерах может быть совершенно любой, хоть проприетарной— клиентам виден только её хеш.
Как человек, однажды год фуллтайм работавший с другим "собственным бинарным протоколом, разработанном с нуля, с встроенным шифрованием и ещё что-то" (*), очень вас прошу — не надо. Я этим уже не занимаюсь, но продолжаю от коллег слышать только плохое и нисколько хорошего.
Мы живём в прекрасное время, когда уже существует https, умееющий в авторизацию по клиентскому сертификату. Уже есть http2 с долгими сессиями и server push. Наконец, уже есть grpc, который всё это красиво оборачивает. Сегодня примерно любая задача передачи данных между двумя акторами эффективно решается широко распространенными инструментами. Изобретать новые почти точно не стоит.
(*) — тут подразумевается телеграм с его MTProto
Собственно, сейчас при желании нет никаких проблем почитать устройство TString, ибо его тащат на гитхаб примерно все опенсорсгые проекты Яндекса (YT, YDB): тык
DeepMind занимался машинным обучением ещё до бума LLM, который сейчас все называют ИИ, и активно продолжает заниматься им и сейчас. Собственно, в этой статье никакой ИИ (LLM) никуда не суют, речи про AGI и близко не идёт, а вместо этого используют вполне привычное машинное обучение для того, чтобы аппроксимировать поведение диффуров и находить скрытые закономерности.
Из блога DeepMind
Our approach is based on the use of Physics-Informed Neural Networks (PINNs). Unlike conventional neural networks that learn from vast datasets, we trained our models to match equations which model the laws of physics. The network's output is constantly checked against what the physical equations expect, and it learns by minimizing its ‘residual’, the amount by which its solution fails to satisfy the equations.
Our use of PINNs goes beyond their typical role as general-purpose tools used for solving partial differential equations (PDEs). By embedding mathematical insights directly into the training, we were able to capture elusive solutions — such as unstable singularities — that have long-challenged conventional methods.
Но на сегодняшний день AI продает лучше чем Machine Learning, вот и суют куда попало.