Hacker News Digest

В FreeBSD находят способ вернуть радость в самохостинг: автор перешёл с Linux, устав от сложностей, и нашёл в BSD простоту, стабильность и отличную документацию.

Ключевые моменты:

• Использует BastilleBSD для контейнеров и vm-bhyve для виртуалок, несмотря на начальную путаницу.
• Ценит долгосрочную совместимость: решения десятилетней давности работают и сегодня.
• Сообщество оказалось невероятно поддерживающим, помогая на каждом шагу.

Автор подчёркивает: важна не идеальная настройка, а сам процесс обучения и радость от экспериментов. Результат — возвращение к хобби-программированию с тем же азартом, что и в юности.

• Участники обсуждают преимущества и недостатки BSD-систем, включая OpenBSD, FreeBSD и производные от них, так как OPNsense и TrueNAS, в контексте самостоятельного хостинга и само-обеспечения.
• Обсуждается, что BSD-системы предлагают высокую стабильность, безопасность и простоту конфигурации, но при этом страдают от недостатка поддержки драйверов и некоторых современных технологий, таких как Docker и systemd.
• Участники делятся личным опытом, включая использование FreeBSD в качестве настольной системы и OpenBSD в качестве маршрутизатора, а также обсуждают, что такие системы могут быть использованы в качестве серверов для различных сервисов, включая Jellyfin и n8n.
• Обсуждается, что BSD-системы могут быть менее удобны для пользователей, которые привыкли к GNU-утилитам и systemd, и что это может быть препятствием для некоторых пользователей.
• Участники также обсуждают, что BSD-системы могут быть менее удобны для разработчиков, так как они могут не поддерживать такие технологии, как CUDA и Docker, что может быть важно для некоторых разработчиков.
• В конце обсуждение переходит к тому, что, несмотря на все вышеупомянутое, BSD-системы все еще имеют свою нишу и что они могут быть полезны для определенных пользователей, особенно для тех, кто ценит стабильность и безопасность.

Linux-ядро может запускаться как обычный процесс в пространстве пользователя без использования традиционного ПО для виртуализации. Эта технология, известная как User Mode Linux (UML), позволяет создавать виртуальные машины без QEMU или прав суперпользователя. UML можно рассматривать как паравиртуализированную конфигурацию ядра, которая использует существующее ядро хоста и его функции пространства пользователя. Вместо прямого доступа к физическому оборудованию, UML использует файлы и сокеты для создания нового экземпляра ядра, способного запускать собственные процессы. Интересно, что драйверы в UML "просветлены" - они осведомлены о работе с виртуализированным оборудованием и могут оптимизировать взаимодействие.

Для сборки UML-ядра требуется платформа x86, где оно может работать поверх существующего x86-ядра. Процесс сборки начинается с команды ARCH=um make menuconfig, где можно настроить специальные опции UML. Важно включить опцию BLK_DEV_UBD, которая позволяет обращаться к файлам хоста как к блочным устройствам. После финализации конфигурации ядро собирается командой ARCH=um make -j16, создавая бинарный файл linux. Интересно, что этот файл является динамически связанным исполняемым файлом с библиотекой C, а не традиционным ядром, работающим напрямую с железом.

• Использ /dev/urandom вместо /dev/zero при инициализации образа диска вызывает вопросы, так как неясно, какой практический смысл в этом есть при отсутствии шифрования.
• UML (User-mode Linux) позволяет запускать ядро как обычный процесс, но ограничен одним CPU и не поддерживает SMP, что ограничивает его практическое применение.
• Появление SKAS (Separate Kernel Address Space) и дальнейшее развитие виртуализации сделали UML менее актуальным, но он всё ещё может быть полезен как промежуточное решение между контейнерами и полноценными VM.

В Ubuntu 25.10 обнаружен баг в Rust-версии команды date из пакета uutils, нарушающий автоматические обновления системы. Проблема затронула облачные развертывания, контейнеры, десктоп и серверные версии. Системы с rust-coreutils версии 0.2.2-0ubuntu2 или ранее подвержены уязвимости, исправленной в версии 0.2.2-0ubuntu2.1. Интересно, что баг не влияет на ручные обновления через apt.

Ubuntu реализует проект "окисления" дистрибутива, переходя на uutils и sudo-rs для версии 25.10, чтобы оценить пригодность Rust-утилит для долгосрочного выпуска в апреле. Этот переход вызвал дискуссию: одни считают, что замена проверенных десятилетиями C-утилит неизбежно приведет к краткосрочным проблемам, другие поддерживают инициативу как необходимую. Также поднимаются вопросы лицензирования MIT вместо GPL и управления проектом uutils.

• Обсуждение вокруг замены GNU coreutils на Rust-версию свелось к тому, что проблема лицензии (GPLv3 vs MIT), а не безопасность, и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.
• Участники обсуждения отмечают, что даже если бы это была уязвимость, то это была бы не более чем типичная для мейнтейнеров Ubuntu ошибка пакетов, которые не были бы исправлены в нужное время.
• Сообщество высказывает опасения по поводу переписывания критически важных утилит, которые были проверены временем, на новом и потенциально менее стабильном языке программирования.
• Некоторые комментаторы подчеркивают, что обсуждение не касается безопасности, а вопрос лицензии и что это не более чем естественное течение времени и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.

Опубликована подробная диаграмма стека сети Linux, созданная Hrvoje Horvat из Ericsson Nikola Tesla. Диаграмма охватывает все уровни сетевого стека: виртуализацию и контейнеры, сокеты, TCP/UDP и нижние уровни с GRO, RPS, RFS и GSO, планировщик сети, NetFilter, управление трафиком, драйверы устройств и функции, ускоренные сетевой картой. Каждый раздел содержит советы по оптимизации и статистику.

Диаграмма доступна в формате PDF (5.4 МБ) и является частью книги "Operativni sustavi i računalne mreže - Linux u primjeni". На момент публикации материал получил 515 просмотров и 380 загрузок. Работа распространяется под лицензией Creative Commons Attribution 4.0 International, что позволяет свободно использовать и распространять диаграмму при обязательном указании автора.

• Диаграмма показывает, как пакет проходит через iptables и Netfilter, что вызвало обсуждение о сложности и важности визуализации в Linux.
• Участники обсуждали, что такие диаграммы редко охватывают контейнеры и виртуализацию, и что отсутствие обновлений может сделать их устаревшими.
• Были вопросы о доступности этих диаграм на разных языках и о том, где можно найти больше информации о книге, из которой они были взяты.
• Также обсуждались вопросы о том, как эти диаграммы могут быть использованы в образовательных целях и о том, что делает их такими полезными для понимания сложных систем.
• В конце, обсуждалось, что такие диаграммы могут быть трудны для чтения в формате PDF и что было бы полезно иметь SVG версию.

Пожалуйста, предоставьте ссылку на статью или более подробную информацию о Sandbox SDK, о которой вы хотите получить пересказ. Без доступа к исходному материалу я не могу создать точный и ёмкий пересказ в требуемом формате.

• Обсуждение выявило, что у сервиса нет мелкого контроля над исходящим трафиком, что критично для безопасности при запуске непроверенного кода.
• Участники отметили резкий рост цен на Cloudflare Containers по сравнению с другими провайдерами, что делает его менее конкурентоспособным.
• Пользователи отметили, что документация и примеры кода в основном ориентированы на JavaScript/TypeScript, что ограничивает использование других языков.
• Несколько комментаторов подняли вопрос о том, что сервис не предоставляет автоматическое уничтожение контейнеров после простоя, что может привести к непредвиденным расходам.
• Некоторые участники обсуждали, что ценообразование и модель биллинга для Cloudflare Containers непрозрачна и может привести к неожиданным счетам.

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

Проект smolBSD позволяет создавать минималистичные BSD-образные операционные системы, собирая их из необходимых компонентов, прямо как конструктор. В основе — микроядро NetBSD, которое загружается буквально за миллисекунды. Пользователи могут добавлять только нужные сервисы, например, SSH или веб-сервер, и получать готовый к использованию образ.

Процесс сборки полностью автоматизирован: достаточно указать нужный сервис в конфигурации, и система сама скачает необходимые пакеты, соберёт образ и подготовит его к запуску. Результат — это минималистичный, но полностью функциональный экземпляр ОС, готовый к работе на любом совместимом железе или в виртуальной среде.

Главная фишка — скорость. Благодаря минимализму, системы на базе smolBSD загружаются практически мгновенно. Это делает их идеальными для edge-устройств, контейнеров или любых сценариев, где важна каждая миллисекунда.

Проект полностью открытый, и его уже можно свободно тестировать и использовать.

• Проект SmolBSD — это минималистичная сборка NetBSD, предназначенная для запуска внутри microVM (Firecracker) и контейнеров.
• Участники обсуждения отметили, что SmolBSD демонстрирует высокую скорость загрузки и минимальные требования к ресурсам, что делает его привлекательным для использования в качестве базового образа для контейнеров и микро-виртуализации.
• Некоторые участники выразили интерес к сравнению SmolBSD с другими минималистичными решениями, такими как FreeBSD и NanoBSD, а также к обсуждению того, какие именно преимущества предоставляет SmolBSD по сравнению с ними.
• Также было упомянуто, что SmolBSD может быть полезен для создания минималистичных образов для контейнеров и микро-виртуализации, и что он может быть использован как альтернатива для таких решений, как Talos или Flatcar Linux.

Разработчики долго спорили, можно ли запускать базы данных в контейнерах. Со временем стало ясно, что лучше использовать облачные решения, где провайдер управляет БД, а не хранить всё в эфемерных контейнерах, которые слишком легко удалить.

В то же время, ключевая инновация Docker — это не изоляция, а стандартизированная упаковка приложений. Вместо ручного редактирования серверов разработчики стали собирать приложения в переносимые образы. Это упростило развёртывание, особенно в облаке, где виртуальные машины требовали настройки вручную. Docker же позволил централизованно управлять образами через реестр, что ускорило разработку.

Важный момент: Docker изначально создавался для PaaS-платформы, чтобы упрощать развёртывание приложений, а не изолировать их. Потому и акцент на сборку, а не на безопасность. Многие функции, такие как read-only rootfs, делали контейнеры безопаснее, но главное — они решали проблему управления.

Кроме того, Docker популяризировал Go, показав его эффективность для системного программирования. Сегодня Go — один из главных языков, а многие стандартные библиотеки включают TLS, что упрощает разработку.

В итоге, контейнеры изменили подход к развёртыванию, сделав его более стандартизированным и автоматизированным. Это помогло DevOps-практикам, хотя некоторые аспекты, как безопасность, развиваются до сих пор.

• Контейнеры появились как реакция на неспособность Linux/Unix обеспечить изоляцию и управление зависимостями, а не как решение для разработки и доставки ПО.
• Docker и подобные инструменты стали популярны, потому что они позволяют разработчикам легко запускать и тестировать приложения в изолированной среде, но это не основная причина их создания.
• Контейнеризация стала возможной благодаря тому, что Google и другие компании внедрили cgroups и namespaces в ядро Linux, что позволило создать легковесную альтернативу виртуальным машинам.
• Использование контейнеров для разработки и тестирования приложений стало возможным благодаря тому, что контейнеры предоставляют изоляцию и контроль над зависимостями, что делает их удобными для этих целей.

Экспериментальный проект WSL-For-FreeBSD переносит компоненты WSL2 на FreeBSD. Он использует тот же ядро и ту же архитектуру, что и WSL2, но адаптирован для FreeBSD. Проект пока не поддерживает GPU и не реализует полную изоляцию, но уже позволяет запускать бинарники Linux в контейнере. Проект открыт и приглашает сообщество к тестированию и PR.

• Обсуждение началось с замечания, что названия вроде «Windows Subsystem for Linux» на самом деле перепутаны и должны бы быть «Linux Subsystem for Windows».
• Участники обсудили, что Microsoft вместо «Windows Services for UNIX» предлагает «Windows Subsystem for Linux» и теперь «Windows Subsystem for FreeBSD».
• Участники обсудили, что FreeBSD используется в Netflix, PS4/PS5, WhatsApp до покупки Facebook и pfSense, но не настолько популярен на десктопе.
• Участники обсудили, что FreeBSD не поддерживает Adobe, Microsoft Office и игры, что делает его непрактичным для десктопа.
• Участники обсудили, что FreeBSD не поддерживает Wi-Fi на ноутбуках Dell, что делает его непрактичным для десктопа.

WinBoat — это инструмент, который позволяет запускать Windows-приложения в Linux с полной интеграцией. Он предоставляет удобный графический интерфейс, автоматизирует установку Windows и обеспечивает доступ к файловой системе Linux из Windows. Проект с открытым исходным кодом, распространяется под лицензией MIT.

• WinBoat – это контейнер Docker с Windows внутри, который запускает приложения в изолированном окружении и предоставляет доступ к ним через RDP.
• Проект не требует лицензии Windows, но юридически он не может быть свободно распространяемым, так как включает в себя не-лицензионные компоненты.
• Пользователи отмечают, что проект не предоставляет никакой новой функциональности по сравнению с существующими решениями, такими как Wine или VirtualBox, и что он не решает проблему, которую он заявляет, что решает.
• Некоторые комментаторы выражают обеспокоенность по поводу того, что проект может быть небезопасен в плане безопасности, так как он требует привилегий root для запуска Docker.
• Проект не предоставляет никакой информации о том, что он делает, и не объясняет, как он это делает, что делает его трудным для пользователей понять, что именно он предлагает.

Wagtail CMS обновил свой веб-сайт, добавив новую страницу «О нас», где описаны основные преимущества и возможности CMS. Вместо традиционных пунктов меню теперь используются интерактивные карточки с иконками, что улучшает пользовательский опыт. На сайте также представлена информация о команде Wagtail, его функциях, доступности и устойчивости, что делает его более прозрачным и доступным для новых пользователей. Обновление подчеркивает важность открытости и удобства, что может привлечь больше разработчиков и контент-менеджеров.

• uv стал фактическим стандартом для управления зависимостями и окружениями, потому что он быстрый и простой в использовании, но это вызвало споры о том, действительно ли он лучше, чем pip и другие инструменты, особенно в контейнерах и CI/CD.
• Некоторые разработчики утверждают, что uv не подходит для контейнеров, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Пользователи, которые привыкли к pip и другим инструментам, иногда утверждают, что uv не предоставляет никаких преимуществ, и что это просто "Rust фанатство", но другие считают, что скорость и простота использования делают его лучшим выбором.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.
• Некоторые разработчики считают, что uv не подходит для использования в контейнерах, потому что он не может использовать системный Python, и это вызывает споры о том, действительно ли это проблема.

Sculptor — это интерфейс для параллельной работы нескольких экземпляров Claude Code в изолированных контейнерах, позволяющий мгновенно переключаться между их средами для тестирования изменений. Он предлагает предложения, которые выявляют критические проблемы по мере написания кода, сохраняя контроль за архитектором.

Инструмент поддерживает традиционный инженерный подход: вы формулируете идеи, а ИИ-агенты занимаются реализацией. Это ускоряет разработку без потери качества, сочетая креативность человека с эффективностью автоматизации.

• Пользователи делятся положительным опытом использования Sculptor для разработки, отмечая удобство параллельной работы и локального выполнения кода в изолированных контейнерах.
• Обсуждаются технические детали работы инструмента: использование контейнеров, поддержка различных моделей ИИ (Claude Code, GPT, Gemini), интеграция с devcontainer и выполнение тестов.
• Высказываются пожелания по расширению функционала: поддержка других языковых моделей и агентов, веб-версия, тёмная тема, настройка переменных окружения.
• Команда разработчиков поясняет план развития: открытие исходного кода, бесплатность для личного использования и возможные платные тарифы для бизнеса в будущем.
• Участники проводят сравнение с аналогичными инструментами (Terragon, Conductor, VibeKit), отмечая различия в подходе к коллаборации и интеграции.

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

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

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

Devbox — это инструмент для создания изолированных сред разработки на основе Docker. Каждый проект работает в собственном контейнере, что предотвращает конфликты зависимостей и сохраняет чистоту основной системы. Контейнеры автоматически перезапускаются и сохраняются между перезагрузками, а код остаётся на файловой системе хоста для удобного редактирования.

Инструмент предлагает простые команды CLI, встроенные проверки безопасности и шаблоны для Python, Node.js, Go и веб-разработки. Также поддерживаются расширенные функции Docker, такие как проброс портов, монтирование томов и настройка переменных окружения.

• Обсуждаются сходства и отличия Devbox от альтернатив: Devcontainers (от Microsoft), Toolbx, Distrobox и других, с акцентом на поддержку в разных IDE и сложность их реализации вне VSCode.
• Поднимается проблема конфликта имен с другими проектами, в первую очередь с Devbox от Jetify, что указывает на возможное отсутствие анализа существующих решений.
• Отмечаются вопросы о безопасности и изоляции, в частности, возможность использования Docker-in-Docker и её последствия.
• Участники делятся личным опытом использования Devbox и аналогичных инструментов, отмечая их удобство для создания воспроизводимых сред без потери производительности.
• Обсуждается, решает ли подход с контейнерами проблему "dependency hell" и насколько он оправдан для разных языков и типов разработки (веб, мобильная).

Агенты ИИ, работающие с файловой системой, представляют угрозу безопасности, особенно в облачных средах. Злоумышленник может обойти защиту на уровне приложения и заставить агента раскрыть конфиденциальные файлы через системные вызовы. Решение — изоляция на уровне ядра, где сам Linux блокирует доступ к нежелательным ресурсам.

Анализ системного вызова open в ядре Linux показывает три точки отказа: do_open (поздний отказ), link_path_walk (средний) и path_init (ранний). Контейнеризация использует эти механизмы, создавая виртуальную файловую систему и пространства имён, чтобы скрыть реальные файлы от процесса. Это надёжнее, чем полагаться на фильтрацию ввода-вывода в приложении.

• Обсуждение методов изоляции и безопасности для AI-агентов, включая контейнеризацию (runc, podman), Landlock и WebAssembly как потенциальные решения.
• Критика предложенного подхода к песочнице как избыточной или неубедительной для экспертов по безопасности, с акцентом на использование существующих проверенных библиотек и методов.
• Уточнение требований к агенту для код-ревью: доступ только к кодовой базе, истории репозитория, диффам, CI/CD логам и системам отслеживания ошибок.
• Обсуждение практических сложностей реализации, таких как неподдерживаемые системные вызовы в gVisor и необходимость баланса между производительностью и безопасностью.
• Скептицизм относительно новизны и точности объяснения автора, с замечаниями, что описанные методы (chroot) не являются полноценной песочницей или контейнеризацией.

Проект Podman Desktop достиг знакового рубежа в 3 миллиона загрузок, что подчёркивает его растущую популярность среди разработчиков. Команда выражает глубокую благодарность сообществу за активное участие: пользователи не только сообщают о проблемах и предлагают новые функции, но и создают расширения, делятся опытом с коллегами и способствуют постоянному улучшению инструмента.

Отзывы пользователей highlight ключевые преимущества, такие как удобство управления контейнерами в едином интерфейсе, работа без прав root и постепенное совершенствование функционала. В честь события запущен специальный сайт-сюрприз, символизирующий признание усилий сообщества.

• Podman рассматривается как бесплатная и более легкая альтернатива Docker, особенно из-за проблем с лицензированием Docker Desktop и его ресурсоемкостью.
• Основные преимущества Podman: возможность запуска без прав root (rootless), лучшая интеграция с systemd и более современная архитектура.
• Для многих сценариев использования Podman является практически прямой заменой (drop-in replacement) Docker, но есть нюансы и отдельные случаи несовместимости.
• Некоторые пользователи предпочитают CLI-интерфейс и не видят необходимости в GUI, как в Podman Desktop.
• Решение об использовании Podman часто связано с конкретными потребностями: работа на ARM/Windows, использование в RHEL, избегание лицензионных ограничений.

musl-аллокатор тормозит в 7 раз
Добавь в main.rs:

#[cfg(target_env = "musl")]
#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

и в Cargo.toml:

[target.'cfg(target_env = "musl")'.dependencies]
mimalloc = "0.1"

Проблема — конкуренция потоков за malloc. Чем больше потоков, тем хуже.
Замена аллокатора нужна даже для однопоточных программ: забудешь — потом дорого.

Почему musl? Статика + 2 МБ distroless-контейнер = старые RH и быстрый cold-start.

Кейс: сервер обрабатывал данные в 7 раз медленнее хоста.
Виноват 200 000 контекст-переключений/сек vs 1 200 у glibc.
strace показал 6,7 с в futex у musl против 0,5 с у glibc.

• musl-аллокатор медленен в многопоточных Rust-программах из-за одного глобального замка.
• Альпийские образы компактны, но «размер» ≠ «скорость»; в проде чаще берут Debian/RHEL.
• Замена: jemalloc, mimalloc или Wolfi (glibc, apk, busybox) без смены менеджера пакетов.
• glibc тоже фрагментирует память; MALLOC_ARENA_MAX=jemalloc спасает.
• Новый mallocng musl не решает конкуренцию потоков: цель musl — минимум кода и харднинг, а не perf.

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 лишь метафора для этой задачи.

nitro — миниатюрный, но гибкий init и супервизор процессов.

Назначение

• init для встраиваемых, десктопных и серверных Linux-систем
• initramfs, контейнеров (Docker, Podman, LXC, K8s)
• непривилегированный демон на POSIX

Конфигурация — каталог скриптов (по умолчанию /etc/nitro).

Требования

• Unix-сокеты
• tmpfs или записываемый /run

Плюсы

• Всё состояние в RAM, работает на read-only root.
• Событийная модель без polling.
• Ноль аллокаций и ограниченных fd во время работы.
• Один статический бинарник + опциональный nitroctl.
• Сервисы — просто каталоги со скриптами, компиляция не нужна.
• Перезапуск, логирование, цепочки логов, независимость от времени.
• Запускается на FreeBSD через /etc/ttys.

Сервис

Каждый подкаталог /etc/nitro может содержать:

• setup — предзапуск, должен завершиться с 0.
• run — основной процесс (не должен завершаться).
• finish — пост-обработка, получает код выхода и сигнал.
• log → symlink на другой сервис для логов.
• down — не поднимать автоматически.
• Имена ≤ 64 символов, без /, ,, переводов строк.
• Каталоги с @ в конце игнорируются (параметризованные сервисы).

Специальные сервисы

• LOG — лог по умолчанию.
• SYS/setup — перед стартом остальных.
• SYS/finish — перед остановкой всех.
• SYS/final — после завершения всех процессов.
• SYS/fatal — при критической ошибке.
• SYS/reincarnate — вместо выключения (полезно для initramfs).

Параметризованные сервисы

Каталог foo@ + symlink foo@bar → запуск foo@/run bar.
nitroctl up foo@baz запустит foo@/run baz даже без symlink.

Жизненный цикл

1. Подъём: SYS/setup, затем все непомеченные down.
2. Работа: перезапуск при падении (пауза 2 с при частых падениях).
3. Останов: nitroctl Shutdown/Reboot → SYS/finish → SIGTERM (7 с) → SIGKILL → SYS/final → reboot/off/exit.

Управление nitroctl

nitroctl [команда] [сервис]

• list — состояния, pid, uptime, код выхода.
• up/down — запустить/остановить (SIGTERM или down-signal).
• start/stop/restart — с ожиданием успеха.
• p/c/h — SIGSTOP/SIGCONT/SIGHUP.

• Участники сравнивают Nitro с runit, s6, dinit и systemd: общие черты — минимализм, отсутствие декларативных зависимостей, ручная настройка порядка запуска.
• Некоторые считают Nitro скорее «голым» супервизором процессов, чем полноценной init-системой из-за отсутствия управления ресурсами, пользователями и параллельного запуска.
• Обсуждаются контейнерные кейсы: одни считают наличие init внутри контейнера избыточным, другие — необходимым при форке процессов.
• Упоминаются альтернативы: собственные минимальные init-системы на C и Rust, а также новый модульный подход в NixOS.
• Критика имени: «nitro» уже занято AWS Nitro, Nitro.js и другими проектами; предлагают сменить название.

Claude Code теперь умеет искать уязвимости: запускает специальный промпт, проверяет OWASP Top 10.
Проверил расширение Simple Wikiclaudia и сервис rsspberry2email — Claude сказал «всё ок».
Но доверять одному ИИ, который сам писал код, нельзя: нужны человеческий ревью, SAST, DAST, фаззинг.

Для контроля подключил Datadog:

• расширение — уязвимостей нет, зато куча логов (HIGH, но можно выключить);
• сервис — Datadog нашёл библиотеки с CVE, предложил кнопку «Remediate».
  Claude подтвердил одну из находок; остальное — «приемлемый риск» для домашнего RPi.

• Руководство верит, что «волшебная пыль ИИ» решает всё, включая проблемы самого ИИ.
• Найденные Claude и DataDog уязвимости выглядят тривиальными и легко детектируются статическим анализом.
• Компании устраивают «тест на компетентность»: удача руководителей вот-вот закончится.
• Пользователи готовы наблюдать, как ИИ удаляет ld, сносит контейнеры и плодит тонны мусорного кода.
• Скоро ИИ займёт ключевые бизнес-процессы, а после провалов и аудитов топ-менеджеры получат золотые парашюты.
• Всё напоминает «Новое платье короля»: все видят проблему, но молчат.

• Проблема цены: Heroku, контейнеры и serverless дорожают при росте проектов.
• Проблема админки: VPS дешёв, но требует обновлений и бекапов.

Решение

1. coreOS/Flatcar — минималистичная ОС, обновляется сама, ставится один раз.
2. Dokploy — open-source PaaS в контейнере: деплой из Git, БД, логи, оркестрация.
3. Итог: VPS-прайс + Heroku-удобство, независимость от облаков.

Когда не подходит: резкие пики нагрузки или совсем старт проекта — бери serverless или Heroku.

• Лицензия Dokploy вызывает вопросы; авторы обещают её переработать.
• Пользователи хвалят простоту и «Heroku-вайб», но жалуются на отсутствие удобного «pull latest», слабое управление секретами и эпизодические проблемы с деплоем.
• Часть аудитории предпочла Coolify (чуть богаче фичами) или старый добрый Dokku/Portainer.
• Для статических сайтов и CI по git-push многие используют Coolify как «домашний Netlify».
• Арм64 поддерживается; wildcard-домены и резервное копирование volume-ов приходится настраивать вручную.

Показываю, как в C сделать обобщённый контейнер maybe, который безопасно возвращает результат, если он есть, и сообщает об ошибке, если её нет.

#define maybe(T) struct { bool ok; T value; }
#define maybe_just(T,x)  { .value = (x), .ok = true }
#define maybe_nothing(T) { .value = (T){}, .ok = false }

static maybe(int) divide(int a, int b) {
    return (b != 0) ? maybe_just(int, a / b) : maybe_nothing(int);
}

Вызов:

maybe(int) p = divide(6, d);
if (p.ok) printf("%d\n", p.value);
else       puts("division by zero");

Чтобы не забыть проверку, добавляем макрос maybe_value, который при ошибке возвращает нулевой указатель, ловим его санитайзером:

#define maybe_value(x) \
    (*({ auto _p = &(x); _p->ok ? &_p->value : (void*)0; }))

Но деление на ноль — не единственная проблема. При делении INT_MIN / -1 возникает переполнение. Исправляем:

maybe(int) safe_divide(int a, int b) {
    if (b == 0 || (b == -1 && a == INT_MIN))
        return maybe_nothing(int);
    return maybe_just(int, a / b);
}

Компилируем с -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=undefined -O2. В ассемблере не остаётся пути к ud2, то есть оптимизатор доказал: переполнения и деления на ноль нет.

Это не делает весь C «безопасным» (жизненный цикл указателей и арифметика не покрыты), но для ограниченных задач подход работает.

• Критика: реализация не заставляет проверять результат, теряя главное преимущество Maybe.
• Ассемблер: GCC выдаёт почти тот же код, что и для std::optional, но не возвращает результат в регистре.
• UB: «пустой» lvalue в случае ошибки вызывает неопределённое поведение; автор полагается на null-sanitizer.
• Эргономика: предлагают добавить and_then/or_else и сделать тип непрозрачным через макросы.
• Почему не другой язык: встраиваемые/фирменные проекты часто ограничены только C или ASM.

Tribblix — ретро-дистрибутив на базе illumos от Питера Трибла.
Свежее: 13 июля 2025 — релиз Milestone 37 (x86, варианты Vanilla и LX).
SPARC: 29 июля 2025 — обновление m32→m33; свежие установки пока через m32 ISO.
SPARC-CD: 15 мая 2025 — ISO m32 помещается на CD.
Поддержка 32-битного железа полностью прекращена. SPARC-версия тестируется слабо, x86 стабилен.
Скачать, установить и использовать можно по ссылкам на сайте.

• Участники обсуждают нишевые ОС (Tribblix, Dragonfly BSD, Haiku, RISC OS, 9front, MINIX) и их «невидимость» на фоне мейнстрима.
• Solaris Zones/LX-контейнеры хвалят за удобство, но установка Illumos-дистрибутивов часто страдает из-за проблем с USB3 и современным «железом».
• Поднимается идея слоя совместимости Linux-драйверов, но критика: это влечёт GPL-проблемы и наследование архитектурных ограничений Linux.
• Совместимость ZFS: пулы Illumos читаются Linux/FreeBSD, но не наоборот, если используются новые фич-флаги OpenZFS.
• Tribblix предлагает 30+ оконных сред, включая CDE и OpenLook, но без старого DeskSet.