Hacker News Digest

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

Разработчики создали формат blockdiff для мгновенных снапшотов дисков виртуальных машин, сократив время создания с 30+ минут на EC2 до нескольких секунд — ускорение в 200 раз. Это стало возможным благодаря хранению только изменённых блоков данных, что экономит место и ускоряет операции. Формат работает поверх CoW-механизмов XFS в Linux, обеспечивая нулевые накладные расходы и мгновенное создание снапшотов без полного сканирования диска.

Ключевые применения включают сохранение сред разработки, быстрое пробуждение ВМ из сна и откат изменений. Решение обошло ограничения бинарных диффов и OverlayFS, предложив простую и надёжную реализацию на Rust. Открытый исходный код доступен на GitHub, что позволяет сообществу адаптировать инструмент для схожих задач.

• Удивление отсутствием рассмотрения формата QCOW2 и технологии тонкого provisioning VDO с LVM2 для решения аналогичных задач.
• Вопросы о выборе XFS вместо ZFS/BTRFS, использовании LVM-снимков и возможности интеграции решения с другими гипервизорами и файловыми системами.
• Обсуждение технических деталей реализации: использование флагов для синхронизации файлов, поддержка copy_file_range в qemu-img, сравнение с OverlayBD.
• Интерес к применению технологии для ускорения подготовки виртуальных машин в CI/CD и публичном облаке.
• Замечания о необходимости альтернативного текста для изображений и выбора лицензии для проекта.

Кодирующие агенты вроде Claude Code и Codex CLI позволяют ИИ не только писать код, но и запускать его, исправлять ошибки и экспериментировать с решениями. Ключевой навык для эффективного использования таких инструментов — проектирование агентских циклов: настройка последовательности действий, где ИИ применяет инструменты в цикле для достижения чётко сформулированной цели. Это превращает агентов в инструменты «грубой силы» для решения задач, если можно определить цель и дать нужные инструменты для итераций.

Однако такая мощь сопряжена с рисками, особенно в «YOLO-режиме», когда агент выполняет команды без подтверждения. Это может привести к удалению файлов, утечке данных или использованию машины для атак. Для снижения рисков автор рекомендует запускать агентов в песочницах (например, Docker), использовать облачные среды вроде GitHub Codespaces или полагаться на удалённые серверы, где ущерб будет ограничен. Также важно тщательно подбирать инструменты для цикла, чтобы агент мог эффективно и безопасно решать задачи.

• Предлагаются альтернативы Docker для песочниц: bubblewrap, firejail, пользовательские аккаунты, KVM и контейнеры.
• Обсуждаются принципы проектирования агентских циклов: избегание фреймворков, малое число мощных инструментов, важность человеческого контроля.
• Подчеркиваются риски безопасности YOLO-режима и необходимость изоляции (контейнеры без сети, VM) для предотвращения утечек данных.
• Отмечается эффективность асинхронных циклов (например, в Claude Code Plan mode) для выполнения задач без постоянного вмешательства.
• Упоминаются практические реализации: MCP, инструменты для работы с документами, использование checkpoint-ов и систем оркестрации.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.

I would see Proxmox come up in so many homelab type conversations so I tried 8.* on a mini pc. The impression I got was that the project probably provides the most value in a clustered environment or even on a single node if someone prefers using a web UI. What didn't seem very c