Hacker News Digest

Разработчик дообучил языковую модель Qwen2.5-Coder-0.5B на 360 млн параметров, чтобы она вела себя как настоящий терминал. За демонстрацией нет ни оболочки, ни файловой системы: каждое нажатие клавиши подаётся на вход, а модель предсказывает, как изменится экран. Она умеет создавать файлы, запускать vim и tmux, играть в «змейку» и обычно помнит, что вы вводили несколько команд назад. Наберите pythoon — и увидите, что это не настоящая оболочка.

Терминал представлен сеткой символов, а не пикселей, поэтому обучающие данные можно генерировать в неограниченном объёме, запуская реальные программы в Docker. Модель не видит сетку напрямую — она получает последовательность токенов с содержимым экрана, позицией курсора и изменениями. Вместо потока текста она предсказывает, какие строки перерисовать и куда переместится курсор. Время тоже подаётся на вход: если ничего не нажато, приходит токен ожидания с длительностью — так «змейка» движется сама. Главные удачи — обучение модели исправлять собственные ошибки и параллельное декодирование строк экрана.

Демонстрация рассчитана на настольный браузер с WebGPU и физической клавиатурой, лучше всего работает в Chrome или Edge. Это загрузка на 208 МБ, всё выполняется локально. В планах — обучение на тысячах случайно сгенерированных приложений, чтобы проверить, сможет ли модель предсказывать поведение программы, которую никогда не видела. Веса обещают выложить позже.

Обсуждение дополняет статью идеями применения проекта, сравнением с аналогами и первыми отзывами. @donperignon отмечает, что в реальных тестах модель работает нестабильнее, чем в демо: она ошибается при создании папок и теряет состояние. @Meleagris и @gdevenyi предлагают использовать модель для создания интерактивных honeypots. @amelius советует развивать идею в сторону симуляции конкретного пользователя или интернета (через lynx) вместо общего терминала. @thorum и @aurareturn видят в этом будущем интерфейсов, где локальные модели генерируют UI в реальном времени. Проект сравнивают с vibeSH (@rowbin), Voidware (@ohadpr) и симуляцией Quake II от Microsoft (@psandor). По мнению @andai, выбор Qwen2.5-Coder в качестве базы оправдан её знакомством с синтаксисом CLI.

Игры PlayStation 2 запускаются прямо в браузере благодаря статической рекомпиляции: машинный код Emotion Engine заранее переводится в C++ и компилируется в WebAssembly, поэтому главный процессор никогда не интерпретируется. Остальная консоль — её операционная система и аппаратура — эмулируется средой выполнения, которая рисует через WebGPU. Первой игрой стала Gran Turismo 4, одна из самых требовательных на системе: она опирается на оба векторных блока, на точное поведение чисел с плавающей точкой в повторах и лицензионных тестах и на графические трюки с чтением отрисованных изображений как палитр. Игра проходит от загрузки через вступительный ролик, меню и гонки, со музыкой и звуками, и сохраняется на карту памяти, хранимую в браузере. Гонка идёт на полной скорости — 50 кадров в секунду для европейской версии — в Chrome на встроенной графике ноутбука при вдвое большем разрешении, чем у PS2.

God of War II заработала на тех же скриптах без кода под конкретную игру, но вскрыла два бага, которых Gran Turismo 4 не вызывала: один в рекомпиляторе, другой в таймингах векторного блока, плюс нехватку частей процессора ввода-вывода. Теперь она идёт от меню через катсцены в бой и держит 60 кадров в секунду в тяжёлых схватках при родном разрешении PS2, а при удвоенном — от 48 до 60, упираясь во встроенную графику. Данные игр не входят в репозиторий: вы приносите образ своего диска, а скрипты превращают его в веб-страницу на вашей машине. Диск читается через HTTP-запросы диапазона, поэтому сначала скачивается только исполняемый файл. Карту памяти можно выгрузить в формате .ps2, совместимом с PCSX2, и перенести между браузерами. Страница требует изоляции источников из-за SharedArrayBuffer, а сгенерированный код принадлежит правообладателям игр — публиковать его нельзя.

Обсуждение вызывает скепсис относительно термина «рекомпиляция», так как проект фактически остается эмулятором с вшитым образом, а не полноценной статической рекомпиляцией. Пользователи @vrighter и @anonymous908213 отмечают, что лишь часть кода переведена в функции, а автор позиционирует проект как «без эмулятора», что противоречит реальности. Сообщество признаёт, что современные LLM ускорили декомпиляцию и рекомпиляцию игр, но это вызывает опасения по качеству и достоверности заявлений. @aceazzameen выражает обеспокоенность скрытым вредоносным ПО, на что @johnfn отвечает, что WebAssembly является одной из самых безопасных сред исполнения. По опыту @kodablah, аналогичный ARM-to-WASM подход для PS Vita работает эффективно в Chrome на флагманских Android-устройствах. Пользователь @Hyperlisk разрабатывает схожий инструмент с фокусом на точность, используя рекомпиляцию в Golang для поддержки SIMD.

OpenDLSS-NR — это Vulkan-реализация нейросети DLSS 5 Neural Rendering от NVIDIA, бит-в-бит идентичная оригиналу. Она воспроизводит ту же архитектуру: U-Net из 71 блока Swin/Vit-трансформеров с глобальным ViT внизу, работающий в FP8 (E4M3) с FP16 накоплением, используя 141 МБ весов. Это генеративная нейросетевая отрисовка (Neural Rendering), которая не увеличивает разрешение, а улучшает уже отрисованный кадр: добавляет детали из шума, корректирует тон, структуру и кожу под стилем, принимая на вход текущий кадр (LDR-прокси), три канала гауссовского шума, репроецированный предыдущий вывод и пять скалярных условий, выдавая RGB-резидуал и логит временного смешивания. Все промежуточные результаты на 75 границах блоков совпадают с оригиналом байт в байт.

Есть независимый порт в браузере через WebGPU (ports/browser-webgpu/), который воспроизводит те же байты без tensor-ядер и FP8 — чисто на шейдерах. Для запуска нужны собственные веса в указанной структуре каталога. Сборка выполняется через PowerShell-скрипты: установка инструментов, сборка шейдеров и PTX, сборка демо на базе Filament. Демонстрация позволяет выбирать сцены из build\scenes и управлять через view.json. Производительность на RTX 4070 SUPER: от 2.8 мс при 768×768 до 29.3 мс при 3840×2160 (241 диспатч на кадр). Доступны переменные окружения для тонкой настройки: маска цепочки экспертов (DLSS5VK_CHAIN_MASK), порог отложенного слияния GEMM (DLSS5VK_DEFER_MAX), валидация и отладка. Проект лицензирован под MIT, не связан с NVIDIA и не предоставляет веса — пользователь отвечает за их законное получение и использование. Полная документация по сети, нумерации, исполнению и кадровому буферу находится в папке docs/.

OpenDLSS-NR воспроизводит архитектуру DLSS 5 бит-в-бит, но её практическая применимость ограничена высокой вычислительной нагрузкой — даже на флагманских GPU. Производительность сопоставима с оригиналом: на RTX 5060 в 1080p — 9.9 мс, на RTX 5090 в 2160p — 8.2 мс, что делает её непригодной для игр при 60+ FPS без топового железа. DLSS 2 и новее используют универсальную модель, персонализация достигается через настройки интенсивности и маскирование объектов на этапе инференса. Веса модели не включены в репозиторий, вероятно, из-за юридических рисков, несмотря на то, что по закону США они не подлежат авторскому праву как результаты работы нейросети. Документация содержит фактические ошибки, например, ложные утверждения о git-игнорировании файлов, которые на самом деле присутствуют в репозитории. Для практического использования требуется доступ к весам, извлечённым из последней версии DLSS 5 в игре NBA — без них проект неполноценен. Реализация использует одностадийную диффузионную модель в пиксельном пространстве — техническое достижение, несмотря на низкую производительность. Она больше похожа на технический демо-проект, чем на рабочее решение для игр — официально доступна только в одной игре. Архитектура включает 71 блок Swin/ViT-трансформеров, работает в FP8 (E4M3) с FP16 накоплением, соответствует описанию оригинальной модели NVIDIA. Временной путь использует репроецированный предыдущий кадр и логиты смешивания для стабильности — критично для устранения артефактов в динамических сценах. Оригинальный DLSS 5 использует дополнительные данные от движка (LOD, UV-карты), но OpenDLSS-NR, вероятно, обходит это, чтобы работать с существующими хуками без изменений рендерера. DLSS 1 использовал персонализированные модели на игру; с DLSS 2 NVIDIA перешла на универсальные — подтверждено техническими отчётами. Споры: некоторые считают, что LLM могли сгенерировать код и документацию, снижая доверие; другие утверждают, что если код работает — это не важно, кто его написал. Также обсуждается, использует ли сеть z-буфер: объясняют, что глубина уже закодирована в RGB-каналах, а добавление z-буфера увеличивает пропускную способность без значимой выгоды. NVIDIA не поддерживает открытые реализации CUDA; несмотря на позиционирование как сторонник open source, её интересы ограничены областями, где она сохраняет контроль. Создание OpenDLSS-NR требует глубокого понимания нейросетевых архитектур и может быть выполнено с помощью современных LLM, что снижает барьер для реверс-инжиниринга закрытых систем.

MicroLLM lab позволяет запускать небольшие языковые модели (25–360 млн параметров) прямо в браузере с ускорением через WebGPU, обеспечивая конфиденциальность и отсутствие серверных затрат. Модели квантованы в формате Q4 (4 бита на параметр), что снижает их размер в 4 раза — например, модель в 100 млн параметров занимает ~50–84 МБ в памяти браузера. Это позволяет использовать их для быстрой триажи запросов, фильтрации спама или определения намерений за миллисекунды, решая, нужен ли дорогой облачный LLM.

Lab предлагает загружать модели через IndexedDB, тестировать их в чат-панели и проводить бенчмарки в отдельной вкладке, генерируя сертификаты производительности. Без WebGPU (на CPU через WASM) скорость составляет 8–20 токенов/секунду, тогда с аппаратным ускорением — 100–300+ токенов/секунду (10–20× быстрее). Доступны модели вроде PetitGPT (125M), SmolLM2 (135M/360M) и MiniMind2 (26M/104M), все под лицензией Apache-2.0. Для работы требуется современный браузер с поддержкой WebGPU (Chrome 113+, Edge 113+, Brave или Firefox с флагом) и включённым аппаратным ускорением.

Обсуждение подтверждает, что микромодели действительно работают в браузере быстро, но выявляет существенные проблемы: перегруженный UI, ограниченная поддержка языков, несовместимость с Firefox и частые галлюцинации моделей, а также подчёркивает потенциал стандартизации через Web Models API.

• Пользователи отмечают, что запуск моделей в браузере происходит очень быстро, что делает их подход идеальным для быстрых демонстраций без серверной части.

• Несколько комментаторов сообщают, что ответы моделей часто бессмысленны или содержат галлюцинации, поэтому их пока сложно применять к реальным задачам, например к рецептам или запросам о населении.

• Большинство отзывов указывают на плохой дизайн интерфейса: мелкий шрифт, перегруженная страница и непонятный футер затрудняют использование даже простого продукта.

• Тесты показывают, что приложение работает в Chromium, но падает в Firefox с ошибкой «GPUShaderStage is not defined», что свидетельствует о проблемах совместимости WebGPU.

• Модели, представленные в MicroLLM Lab, обучены только на английском, запросы на других языках, например немецком, просто отдаются без обработки.

• Некоторые участники демонстрируют, что с помощью WebGPU можно запускать более крупные модели в виде одностраничных HTML‐приложений, даже в изолированных (air‐gapped) средах.

• Совет: Для упрощения доступа к локальным моделям в браузерах рекомендуется следить за развитием стандарта Web Models API, который предлагает единый интерфейс для запуска открытых весов.

На macOS вредоносный WebGPU-шейдер на незащищённом сайте может полностью заморозить графический стек, сделав рабочий стол неработоспособным до принудительной перезагрузки. Достаточно одного клика по ссылке — проблема воспроизводится в Chrome, Firefox и Safari на M-серии Mac под macOS Tahoe, но не на других ОС. Шейдер содержит простой бесконечный цикл в compute-шейдере, который непрерывно копирует данные в буфер, блокируя доступ к нему вершинному шейдеру. Это создаёт конфликт доступа к GPU, который перегружает WindowServer — процесс, отвечающий за отрисовку интерфейса. В результате пользователь может увидеть пляшущий курсор, beachball, артефакты на экране или полную потерю отклика UI, хотя остальная система (например, SSH) остаётся доступной. Через некоторое время watchdog-трекер обнаруживает зависание WindowServer и инициирует kernel panic, приводя к принудительной перезагрузке. Пользователь может ускорить процесс, удерживая кнопку питания.

Эта уязвимость напоминает аналогичную проблему 2023 года — ShadyShader, использующую WebGL и получившую CVE-2023-40441 со средней степенью тяжести (CVSS 6.5). Apple тогда усилила проверку на бесконечные циклы в WebGL, но, как показывает Deathray, аналогичная защита в WebGPU оказалась недостаточно строгой — простой цикл без инкремента легко проскакивает валидацию. Хотя Apple официально не считает такие зависания проблемами безопасности (ссылаясь на отсутствие утечки данных или удалённого выполнения кода), автор отмечает, что для обычных пользователей это нарушает фундаментальное доверие к браузеру: клик по ссылке не должен приводить к полной потере управления машиной. Он призывает Apple исправить проблему, но без отключения WebGPU по умолчанию, и предлагает рассматривать такие эффекты как часть этичного эксперимента — например, в играх с добровольным согласием пользователя. Пока исправления нет, он предупреждает: не нажимайте на ссылку, если не готовы к перезагрузке.

WebGPU-шейдер с бесконечным циклом может полностью заморозить графический стек macOS (включая WindowServer), требуя принудительной перезагрузки — проблема воспроизводится на M1/M2 Mac и подтверждена множеством пользователей. Аналогичные атаки через WebGL и OpenCL известны с 2011 года, но macOS до сих пор не имеет GPU-таймаута, в отличие от Windows и Linux, где такие запросы прерываются драйвером. Проблема также наблюдается на Android (Pixel 10) и iOS (в Chromium-браузерах), но не в Firefox, что указывает на различия в реализации GPU-контекста. На Windows и Linux атаки вызывают только сбой вкладки, а не систему. Apple классифицировала репорты как не имеющие «безопасностного значения», что вызывает критику: отказ от восстановления после зависания GPU — архитектурный провал. Даже после завершения браузера GPU-состояние остаётся повреждённым, система тормозит днями — признак утечки ресурсов в драйвере Metal. WebGPU позволяет использовать сложные конструкции (например, Duff’s Device), способные сбивать компилятор Metal, но редко вызывают kernel panic; в вебе же они блокируют весь графический стек. Споры: одни считают это только DoS-атакой (нет утечки данных), другие — реальным ущербом из-за потери сессии и принудительной перезагрузки. Одни настаивают, что отключение WebGPU ломает Figma, Canva и Google Maps, другие — что безопасность не должна жертвоваться ради удобства коммерческих сервисов. Советы: — Пользователям macOS с автовосстановлением сессий: отключите его, иначе после перезагрузки вредоносная страница откроется снова. — Для работы с ненадёжными WebGPU-сайтами рекомендуется использовать Windows или Linux. — Разработчикам: таймауты и ограничения циклов в шейдерах должны быть встроены в API, а не полагаться на драйверы — иначе веб-приложения станут вектором системных атак.

Deno’s runtime includes a dedicated section for desktop application development, offering a full suite of tools and APIs to build cross‑platform GUI programs. It walks developers through project setup, backend integration, HTTP serving, framework choices, and OS‑specific packaging, while also covering advanced features such as WebGPU rendering, hot‑module replacement, DevTools, auto‑update mechanisms, error reporting, and distribution pipelines.

The guide is organized into many subsections—configuration, backends, serving, frameworks, Windows, WebGPU, bindings, menus, tray & dock, dialogs, notifications, HMR, DevTools, auto‑update, error reporting, distribution, and comparison—allowing developers to pick the exact capabilities they need. Notable points include built‑in auto‑update support, WebGPU for modern graphics, and a modular architecture that lets you enable only the pieces you use, making large‑scale desktop projects more maintainable. It also details testing approaches, continuous‑integration hooks, and the CLI commands for scaffolding, bundling, and publishing desktop applications. Security is built‑in, requiring explicit permissions for file, network, and environment access, while TypeScript is supported natively. The documentation also compares different frameworks, helping developers choose the most suitable one for their use case.

• Обсуждается внедрение общего CEF‑рантайма для Deno Desktop, чтобы сократить размер бинарников до нескольких мегабайт.
• Планируется интеграция с системой прав Deno, чтобы пользователь мог удобно просматривать и управлять разрешениями.
• Сравнение с Tauri и другими решениями: возможность использования собственного CEF, несколько бекендов (CEF, WebView, raw) и вопросы размера пакетов.
• Текущий размер приложений остаётся высоким (от 15 МБ с сжатием до 40‑440 МБ), вызывают вопросы по оптимизации и будущей поддержке мобильных платформ.