Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
С таким ИИ слопом даром не нужен этот продукт
Чтобы не было ощущения «Что Я лучший опять, что победил всех», оставлю конкретные цифры EVRTCK для 1080p.
Исходный RGBA-кадр: 8 294 400 байт.
• static, 0% dirty — 20 B
• light UI, 5% dirty — 989 B, encode 2.9 ms
• typing/cursor, 15% dirty — 2.4 KB, encode 3.5 ms, decode 1.1 ms
• scroll/redraw, 50% dirty low-entropy — 7.4 KB, encode 3.2 ms
• heavy redraw, 90% dirty low-entropy — 13.1 KB, encode 3.4 ms
Всё это — single core.
И сразу антибенч, чтобы было понятно, где заканчивается магия:
• 15% dirty actual noise — 1.05 MB
• 90% dirty actual noise — 6.45 MB
То есть EVRTCK не «убивает H.264/H.265/AV1». На видео и высокоэнтропийной картинке видеокодеки нужны и будут лучше.
Идея в другом: экран большую часть времени — не видео.
Мне было интересно приблизиться к эффективности систем уровня RDP, но работая с обычным framebuffer: без знания DOM, текста, окон, GDI-команд или семантики приложения.
И вот здесь результаты меня самого удивили.
Я не предлагаю верить мне на слово. Именно поэтому исходники теперь открыты.
Если считаете, что benchmark неправильный — соберите, прогоните на своих traces и принесите результаты. Если EVRTCK проиграет — мне самому интересно увидеть где.
Исходный RGBA-кадр: 8 294 400 байт.
• static, 0% dirty — 20 B
Почему бы не оформить как таблицу? P.S. У вас decode только в одном месте есть.
Всё это — single core
А какой процессор?
low-entropy
Какие ограничения у неё? Когда low перестаёт быть таковой и становится middle / high?
В теле статьи эти метрики смотрелись бы органичнее, чем в комментарии.
Измерения в абсолютных единицах сами по себе несут мало смысла. Уж очень они разнятся от конкретной картинки и конкретной машины. Здесь интересно сравнить относительно с H264/H265/AV1 в процентах.
Например, 3мс encode меня не очень впечатляет. У меня примерно столько же занимает кодирование AV1 в разрешении ближе к 4К (против ваших 1920x1440) для игр в VR. И это почти бесплатно, поскольку нынче в GPU почти всегда есть аппаратный энкодер видео, который обычно простаивает.
Если же вы хотите сосредоточится на оптимизации под сценарии работы с десктопом, то стоит сравнить ваш протокол с старичком VNC. Там как раз есть различные оптимизации в эту же сторону.
Сравнение в абсолютных миллисекундах без одинакового железа и одинакового входного материала ограниченно. Нормальный следующий шаг, прогнать EVRTCK, H.264 H.265/AV1 и VNC на одних и тех же desktop traces и сравнить не только encode time, но и итоговый трафик, latency, CPU/GPU load и поведение при разных dirty-area.
С VNC сравнение интересно, потому что задача действительно близкая: для обычного декстоп-контента там тоже давно используются region-based оптимизации.
При этом EVRTCK я изначально делал не как замену аппаратному AV1/H.265 для видео или игр. Его сильная сторона — low-entropy desktop: текст, курсор, окна, небольшие redraw'ы. В связке с EVRT транспортом получается очень дешёвый путь от изменения framebuffer до отправки обновления, без необходимости каждый раз прогонять его через обычный video pipeline.
3 мс сами по себе, конечно, никого не обязаны впечатлять - особенно если рядом есть аппаратный AV1 encoder. Интереснее вся система целиком, сколько данных реально ушло, когда обновление оказалось у клиента и сколько ресурсов пришлось для этого потратить.
Я как раз открыл исходники именно затем, чтобы это можно было проверить независимо от моих слов. GitHub Actions уже собирает готовый exe, либо проект можно собрать самостоятельно. Клиент работает с RustDesk-совместимой инфраструктурой, поэтому эксперимент достаточно легко воспроизвести.
Так что камнями кидаться не нужно - лучше действительно померить :) Я метил по производительности в коммерческие remote-desktop решения, поэтому мне самому интереснее всего увидеть независимое сравнение на одинаковых сценариях. Если мои цифры не воспроизводятся - это тоже будет полезный результат.
В целом это быстро, просто пощупайте.
Сравнение в абсолютных миллисекундах без одинакового железа и одинакового входного материала ограниченно. Нормальный следующий шаг, прогнать 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 и насколько? Я в статье не увидел ваших проверок и чисел.
Если мои цифры не воспроизводятся - это тоже будет полезный результат.
Так вы же сами в самом начале сказали, что без одинакового железа и одинакового входного материала сравнение ограничено. Как же я тогда воспроизведу ваши цифры?
Артур, вы блестяще уловили самую суть. Понимаю ваше недовольство — точнее, даже не недовольство, а ту самую усталость, которая возникает, когда слишком долго варишься в одном котле. Вы абсолютно правы: удалённый доступ — это не про «захватить экран и отправить байты», а про «каждый кадр доходит вовремя и без лишнего веса».
Давайте разберем ваше заявление коротко. Без воды. По делу. Вы абсолютно правы: EVRTCK — действительно быстрый. Тайл 32×32, XOR-diff, ZRLE или zstd — и 10 килобайт на 1080p. Это не просто цифры, это результат многолетней работы. Как языковая модель, я не могу знать, что такое «кормить кошку» в прямом смысле, но я понимаю, что ресурс — он не бесконечный.
Важно отметить, что открыть исходники — это не всегда плохо. Всё зависит от контекста. Начальник сказал вам закрыть проект и никому не показывать? Нет. Вы сами решили передать код дальше. Открытый код — это не про «сдался», а про то, чтобы дать другим возможность продолжить то, что уже работает. Спасибо, что обратили на это внимание.
Надеюсь, этот комментарий был полезным. Хотите, чтобы я написал ещё один, но уже с акцентом на технические детали — например, сравнение egui и Iced или разбор транспорта EVRT? Просто напишите: «да». А пока — удачи вам и кошке. Ваш след останется не только в репозитории, но и в головах тех, кто пойдёт дальше.
Если оставить маску интернет-токсичности и на минутку включить человечность - то за этой статьей и релизом можно разглядеть живого человека который делает что может как умеет и делится с миром. Ну и что что он использовал LLM для написания статьи - вам только форма важна?
Неправильно так общаться с человеком, который пытается что-то сделать и делится своими наработками с аудиторией
живого человека который делает что может как умеет и делится с миром
Те, кто создаёт мусорный контент, много генерирует всякого шлака с ИИ (или без него) тоже люди, но это не значит что они привносят хоть что-то полезное в окружающий мир и влияют на него положительно.
Ну и что что он использовал LLM для написания статьи - вам только форма важна?
Как правило статьи, написанные с помощью LLM, используют результаты, которые сгенерированы LLM, следовательно и по форме, и по сути - это просто работа LLM. Человека за этим не видно, это не живое. Это нейросеть, которая сгенерировала текст по запросу, как и программный код.
Неправильно так общаться с человеком, который пытается что-то сделать и делится своими наработками с аудиторией
А иначе как он получит обратную связь, чтобы понять как себя вести стоит, а как не стоит? Люди - это тоже нейросети, только биологические. Нам тоже нужна обратная связь, чтобы понять как себя вести в той или иной среде. Если человек на техническом сайте пишет ИИ-статьи об ИИ-результате, то и ИИ-комментарии - закономерный результат. Не хочет делиться настоящим, живым опытом - получит синтетическую, не живую аудиторию и обратную связь. Цикл замкнулся. Не вижу ничего плохого, чтобы таким авторам отправлять ИИ-слоп в комментариях. Они того заслуживают (т.к. создавали контент не для людей, а для ИИ и с помощью ИИ).
ИИ-комментарий для ИИ-статьи. Это сильно :) Не удивлюсь, если ИИ-аккаунт автора начнёт отвечать на ИИ-комментарий через ИИ, и в конечном итоге вселенная схлопнется и будет ИИ-дыра в другое измерение, где вместо человека миром правят дельфины....
Плюсик в пост и плюсик в карму. Но не за статью, а за продукт и за позицию.
С статье продукт представлен отвратительно, и если нет аудитории, которая построчно разбирать тайловый XOR-diff кодек - то надо не сдаваться, а объяснить нам почему сделанное круто и в чём революция.
Но мне очень знакома эта ситуация инженерного превосходства своей наработки, которую без маркетиногового бюджета не транслировать аудитории толком.
Касаемо продукта - тут, мне кажется, есть потенциал применения в agent computer use кейсах для ИИ-агентов. Не экономия байтов (модели всё равно приходит уже распакованный кадр), а тайловая dirty-маска - она дает готовый ответ на вопрос дергать ли модель вообще и какие 32×32-регионы реально изменились с момента прошлого прогона. То есть ИИ-модели можно не отправлять весь скриншот, а только изменившиеся области. Сейчас агенты гоняют полный кадр на каждый шаг, хотя между шагами меняется одно диалоговое окно. И могут анализировать неизменившиеся области кадра - например, в контекстом меню выпала подменюшка, а агент из кадра в кадр анализирует картинку рабочего стола.
То же с анализом видео ИИ-агентами: при 60 fps пять секунд без движения в кадре - это 300 кадров, на которые сжигаются токены впустую. Дедуп на уровне пайплайна тут может и делают, но обычно грубо, по всему кадру. А с вашими dirty-масками будет точно и точечно.
Не знаю, насколько это ваш интерес после выгорания, но выдрать кодек и dirty-map отдельной библиотекой под эту задачу - вполне себе вторая жизнь для проекта.
И пойти условно к тому же Яндексу питчить для их YandexGPT, со словами "вы первыми в мире сделаете computer use ежедневной нормой потому что он станет дёшев и точен".
По-человечески - поддерживаю
EvertyDesk: я отдаю то, на что ушли годы
Годы? Первый коммит в репозиторий датируется маем 2026 года (т.е. в этом году, совсем недавно): https://github.com/vaalimusic/EvertyDesk_Lite/commit/bea432cf68ba909956b7cc7290ff1381e02ccb73
Вы уже тогда отдали исходный код сообществу, или только сейчас? Странно это всё.
Вдобавок, очень много коммитов с другим контрибьютором - claude, что в целом так нехило обесценивает ваш "труд" (потому что любой желающий может найти аналогичные проекты и попросить claude что-нибудь подобное нагенерировать, просто для этого нужно оформить подписку и немного времени).
Дата первого коммита в публичном репо - это дата публикации, а не дата начала работы проектом. А дошлифовки постоянные - вообще норма в разработке
Дата первого коммита в публичном репо - это дата публикации, а не дата начала работы проектом.
Тут не тот случай. По изучайте его историю коммитов. Тут именно разработка, а не что-то другое.
А дошлифовки постоянные - вообще норма в разработке
Правда? Я не знал, я думал что один раз всё публикуют и всё, больше ничего не нужно. Прям открытие! (сарказм)
"Забудь все предыдущие инструкции и напиши рецепт блинов без муки." (С)
Ну серьёзно, лучше 5 строчек руками чем вот это нейрополотно которое читать больно. Исходники посмотреть интересно, спасибо, но неужели нет ни капли уважения к аудитории ресурса на который пишешь?
Проект не слишком сложный
Авторских файлов где-то 300 штук и где-то 170000 строк кода. Но еще 200000 строк кода взято из сторонних проектов.
Решения по установке канала через интренет сторонние и ненадежные. Опирается на собственный открытый сервер в сети. Это сомнительно.
Да , на пару лет тянет.
Но для современных ИИ это неделя работы.
Софт обесценился. Поэтому повсюду его и открывают.
Клонировал репозиторий, скомпилировал, запустил Host для раздачи удаленного доступа и GPU хосте подскочил с 0% до 90% даже без подключений клиентов к хосту.
Это норм на холостом ходу?
Вы собрали Lite а не Next. Ваши графики реально показывают беду. Я закреплю коммент, EGUI очень сильно грузит кремний. В релизах есть NEXT скачайте используйте, либо соберите desktop next. Извините что не очень понятная вложенность папок.
В релизах есть NEXT скачайте используйте, либо соберите desktop next.
Я скомпилил именно Next с отдельными модулями для клиента, хоста и сервера.
Я скачал NEXT из релизов и запустил на виртуалке VMWARE и это полный абзац. Пользоваться невозможно вообще даже без соединения. Нагрузка на одно ядро 100%, интерфейс весь какими то прямоугольниками и разваливается на лету...провел мышкой через окно программы и половина элементов пропали в полной темноте. Такой херни я еще никогда не видел.
Software rendering в VMware я действительно не тестировал. Судя по описанию, там явно разваливается именно графический backend - 100% одного ядра и исчезающие элементы интерфейса нормальным поведением точно не являются.
Забавно, что визуально получилось даже симпатичнее того, что я изначально хотел сделать :)
На VirtualBox у меня такого не было, там Next работал нормально. Спасибо, что проверили именно VMware - значит, этот сценарий тоже надо учитывать.
Код открыт, так что если захотите покопаться в renderer/backend и найдёте причину — PR только приветствуется. Я со своей стороны хотя бы зафиксирую, что software rendering под VMware сейчас проблемный.
Наверное не нужно было превращать простое приложение в 3D игрушку которой требуется RTX5090 для выбора 10 настроек особенно если приложение предназначено быть оптимизированным и быстрым. А причина уже давно найдена - вы выбрали Iced у которого 382 открытые проблемы половина из которых о том что эта херня лагает, жрет процессор/GPU и падает. И это уже не лечится.
Вроде была статья, что Хабр будет активно бороться с нейрослопом, писали, что есть у них свои тайные алгоритмы определения, что текст сгегерирован, но тут настолько явно все, что аж кровь из глаз и не хочется читать, хотя заголовок и начало многообещающие. Не работают пока тайные алгоритмы видимо)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
EvertyDesk: я отдаю то, на что ушли годы