Hacker News Digest

Podman v6.0.0 выходит с полной переработкой сетевого стека: вместо slirp4netns и iptables используются Netavark, Pasta и nftables, что упрощает поддержку и готовит почву для новых функций. В экспериментальном Pesto‑переадресаровании портов сохраняется исходный IP‑адрес rootless‑контейнеров, а поддержка нескольких провайдеров в podman machine теперь включает команду os update для автоматического обновления виртуальных сред.

Quadlet‑юниты получили REST‑API, более надёжное отслеживание связанных файлов, расширенный набор .volume‑опций и дополнительные пути поиска для удобного распространения. Конфигурационные файлы переработаны, чтобы проще управлять настройками в многопользовательских сценариях, а поддержка Docker‑API усовершенствована, упрощая миграцию. В релизе более 150 исправлений и новых возможностей, что делает управление контейнерами быстрее, безопаснее и удобнее. Команда благодарит всех участников, особенно новых вкладчиков, за их вклад в проект.

• Переход с Docker Desktop на Podman стал простым: достаточно установить и указать на docker‑compose.yml без изменений, при этом избавиться от постоянного демона.
• Podman предлагает rootless‑контейнеры, quadlet‑шаблоны и интеграцию с systemd, что упрощает управление сервисами и мониторинг.
• Существуют несовместимости: некоторые функции Docker‑CLI работают иначе, требуются дополнительные флаги, а также проблемы с сетью и поддержкой разных дистрибутивов.
• Пользователи отмечают улучшения в новых сетевых инструментах Podman и быстрый переход к ним, однако остаются вопросы по документации и миграции сложных compose‑файлов.

В 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-системы все еще имеют свою нишу и что они могут быть полезны для определенных пользователей, особенно для тех, кто ценит стабильность и безопасность.

В 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 версию.

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

В то же время, ключевая инновация 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, и это вызывает споры о том, действительно ли это проблема.

Кодирующие агенты вроде 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 лишь метафора для этой задачи.