Hacker News Digest

Проект 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, избегание лицензионных ограничений.

Systemd всё чаще становится причиной скрытых ограничений для демонов, вызывая ситуации, когда служба работает при ручном запуске от root, но отказывает в штатном режиме. Это происходит из-за директив вроде ProtectHome= (блокирующей доступ к домашним каталогам) или PrivateTmp= (создающей изолированный /tmp), которые могут приводить к "таинственным" ошибкам вроде "permission denied" или исчезновению файлов в /tmp.

Особенно коварны ограничения на IP-адреса, которые могут неожиданно блокировать DNS-запросы, если демон не использует systemd-resolved. Пока проблему можно решить, удалив ограничения из .service-файла, но в будущем некоторые демоны могут начать требовать эти настройки, что усложнит диагностику.

• Обсуждаются возможности systemd для изоляции и ограничения сервисов через настройки юнитов, что может служить альтернативой контейнеризации.
• Поднимается вопрос сложности отладки и логирования при использовании усиленных настроек безопасности systemd.
• Участники делятся практическим опытом настройки hardening'а для конкретных сервисов (например, Jellyfin) и решения возникающих проблем.
• Высказываются полярные мнения о systemd: от критики за усложнение и нарушение UNIX-принципов до поддержки за гибкость и мощные функции.
• Затрагивается тема культурного феномена хейта вокруг systemd и его сравнение с другими инструментами (Docker, Podman).

Коротко: домашний DNS на BIND

• Цель: локальный DNS для сети homelab.jhw, работающий без интернета.
• Сервер: Raspberry Pi 4 (inf01.homelab.jhw, 192.168.1.10) под Fedora 42.
• Сети: 192.168.1.0/24, 172.16.0.0/16, 10.88.0.0/16 (Podman).
• Форвардер: Fritz!Box 7490 (192.168.1.254) — чтобы резолвить DHCP-имена.

Установка

dnf install bind bind-utils
firewall-cmd --add-service=dns --permanent

Конфиги

• /etc/named.conf — слушаем 127.0.0.1, 192.168.1.10, 172.16.1.10, 10.88.0.1; форвард на Fritz!Box; отключён DNSSEC.
• Зоны:
  – forward.homelab.jhw → A-записи хостов.
  – reverse.homelab.jhw → 1.168.192.in-addr.arpa.
  – reverse2.homelab.jhw → 16.172.in-addr.arpa.

Пример forward.homelab.jhw

$TTL 86400
@   IN SOA  inf01.homelab.jhw. root.homelab.jhw. (
        2025082901 ; serial
        3600       ; refresh
        1800       ; retry
        604800     ; expire
        86400 )    ; minimum
        IN NS   inf01.homelab.jhw.
inf01   IN A    192.168.1.10
ca      IN A    192.168.1.10
hl01    IN A    192.168.1.11
hl02    IN A    192.168.1.12
hl03    IN A    192.168.1.13

Проверка

named-checkconf
named-checkzone homelab.jhw /var/named/forward.homelab.jhw
systemctl enable --now named
dig @192.168.1.10 ca.homelab.jhw

Готово: локальные имена резолвятся даже без интернета.

• Кто-то дома поднимает Technitium DNS в контейнере: DoH/DoT, блокировка рекламы, API — проще, чем Pi-hole.
• Другие предпочитают unbound (кэш/рекурсия) + nsd (авторитетный), dnsmasq (DHCP+DNS без перезапуска) или CoreDNS «всё-в-одном».
• BIND считают мощным, но громоздким: «много конфигов, как Gentoo»; PowerDNS и NSD выглядят проще.
• Внутренние зоны: .lan, .internal, .home.arpa или «публичный домен, но только в LAN» — спор о риске коллизий и TLS-сертификатах.
• Apple-устройства могут игнорировать «левые» TLD, если не добавить сервер в профиль или не внедрить собственный CA.
• Кто-то кодит DNS на коленке (dns4j), кто-то мечтает купить публичный TLD за 50 млн долларов, лишь бы не зависеть от регистратора.

• Кто-то в восторге от Podman: нет лицензий, rootless, systemd-интеграция, podman generate kube.
• Кто-то страдает: старые версии в Ubuntu, тормоза, сетевые сбои, SELinux, UID-маппинг, compose не докручен.
• Docker упрекают в daemon-root и тяжёлом демоне, но хвалят за «просто работает» и DX.
• Часть вообще ушла в FreeBSD Jails, OrbStack, Colima или bash-скрипты на VPS.
• Вывод: Podman годится, если готовы поборотьься; иначе остаёмся на Docker или ищем третий путь.

• Рисование
  Терминал умеет только моноширинные символы и escape-последовательности. Используем нижний полублок ▄, задавая цвет фона (верхний пиксель) и символа (нижний).

  fn print_pixels_pair(top, bottom, (x, y)) {
      println!("\x1b[{};{}H\x1b[48;2;{t}m\x1b[38;2;{b}m▄", y+1, x+1, t=top, b=bottom);
  }
  

• Текст
  Создаём TextCaptureDevice в Skia: перехватываем onDrawGlyphRunList, преобразуем glyph → Unicode, вызываем Rust-функцию draw_text.
  Добавляем очистку текста при заливке прямоугольников:

  if (paint.getStyle() == kFill_Style && paint.getAlphaf() == 1.0)
      clear_text(rect);
  

• Ввод
  Читаем stdin, парсим escape-коды клавиш/мыши, передаём их в Chromium через DOM-события.

• Pipe-режим
  carbonyl --pipe рисует в stdout, позволяя встраивать браузер в скрипты.

• Mojo
  Заменяем GPU-процесс на заглушку, отключая лишние сервисы.

• Layout
  Подгоняем device_scale_factor и viewport под размер терминала, чтобы 1 px = ½ клетки.

• LoDPI
  На 1×-экранах включаем сглаживание, чтобы символы не «дребезжали».

• Цвет
  Палитра 6×6×6 или 24-бит truecolor; приводим цвета к ближайшему доступному.

• Заголовок
  ESC-операторы меняют заголовок окна и вкладки tmux.

• Итог
  Carbonyl запускает весь веб в терминале без X11/Wayland: cargo install carbonyl.

• Carbonyl — терминальный браузер на движке Chrome, удивительно шустрый и юзабельный, особенно с --zoom=300 --bitmap.
• Пользователи просят добавить Kitty Graphics Protocol, sixel/chafa для нормального вывода картинок без ASCII-арта.
• Проект вдохновлён browsh, но работает быстрее; автору даже помог получить работу.
• Запускается в podman, показывает YouTube «кубиками» и почти справляется с капчей (могут помочь мультимодальные LLM).
• Под капотом — Skia и Mojo из Chromium, что позволяет рендерить всё, включая PDF.

ghrc.io — опечатка к ghcr.io — маскируется под реестр контейнеров, но крадёт GitHub-токены.

Как работает атака

• Обычные пути (/, /404) возвращают стандартную страницу nginx.
• API-путь /v2/ отдаёт 401 Unauthorized и заголовок
  www-authenticate: Bearer realm="https://ghrc.io/token".
  Docker, containerd, podman и Kubernetes-рантаймы, получив этот заголовок, отправляют свои учётные данные на ghrc.io/token.

Когда утекут токены

• docker login ghrc.io
• GitHub Action docker/login-action с registry: ghrc.io
• Секрет Kubernetes для ghrc.io

Простой docker pull ghrc.io/… без логина не передаёт токенов.

Что делать

Если вы когда-либо логинились на ghrc.io:

1. Смените пароль GitHub.
2. Отзовите все PAT и OAuth-токены.

• Пользователи обсуждают, что домен-ошибка ghrc.io (вместо правильного ghcr.io) уже зарегистрирован и может использоваться для атак.
• Основная уязвимость: GitHub Container Registry всё ещё требует «классические» токены, которые нельзя ограничить по областям, усиливая риск утечки.
• Многие открытые проекты уже ошибочно используют ghrc.io в конфигах CI/CD, что делает атаку массовой.
• Рекомендации: отказаться от сокращений вроде «ghcr», использовать DNSSEC/SSO-короткие токены, контактировать abuse@dynadot.com для блокировки злоумышленного домена.

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 и другими проектами; предлагают сменить название.

Для сборки Docker Compose-проекта без Docker используются Podman, Docker Compose CLI и BuildKit.

Проблемы

• Podman предлагает два варианта:
  – официальный docker-compose, но без BuildKit (нет additional_contexts);
  – podman-compose, но без !reset, configs и т.д.
• Постоянно догонять новые фичи Docker Compose не хочется.

Решение

1. Запускаем официальный docker-compose через Podman

   pacman -S docker-compose docker-buildx
   systemctl --user start podman.socket
   docker context create podman --docker host=unix://$XDG_RUNTIME_DIR/podman/podman.sock
   docker context use podman
   

   Compose автоматически поднимает контейнер buildx_buildkit_default.

2. Собственный BuildKit-демон (systemd)

   pacman -S buildkit
   systemctl --user start buildkit.service
   docker buildx create --name local unix://$XDG_RUNTIME_DIR/buildkit/rootless
   docker buildx use local
   

3. Убираем демон: Bake → Bakah

   • docker buildx bake --print >bake.json – экспорт в JSON.
   • Bakah превращает JSON в вызовы Buildah (без демона).

   docker buildx bake --print >bake.json
   bakah --file bake.json
   

Bakah пока без HCL, переменных и прочих продвинутых фич, но достаточно для сложных проектов.

• Podman предлагает альтернативы Docker-Compose: kube-файлы, systemd-интеграцию и Quadlets, но у compose-режима есть баги (зависимости «убивают» общие сервисы).
• Многие разработчики всё же возвращаются к Docker/Compose или OrbStack/Colima из-за привычного UX и меньшей борьбы.
• Для продакшена без Kubernetes рекомендуют Docker Swarm или Quadlets, которые «встраиваются» в systemd.
• Rootless-режим в Podman работает «из коробки», тогда как в Docker требует ручной настройки.
• Поддержка multi-arch-сборок и BuildKit в Podman есть, но сложнее, чем у Docker.

• Цель: создать единый фреймворк для тестов производительности Ollama на двух конфигурациях:

  1. настольная материнка (1×CPU, 1×GPU, 128 ГБ ОЗУ);
  2. кластер из 4 узлов (по 64 ГБ ОЗУ, 1×GPU, 10 GbE).

• Методика

  • Одинаковые образы Docker/Podman на обеих платформах.
  • Набор моделей: llama3.1:8b, codellama:13b, mistral:7b, qwen2.5:32b.
  • Метрики: t/s, TTFT, TPS, Watts, $/1k токенов.
  • Повторять 3×, усреднять, выводить ±σ.

• Автоматизация

  • Ansible-playbook разворачивает Ollama, node-exporter, prometheus, grafana.
  • Скрипт run-suite.sh последовательно запускает каждую модель с 512, 2 048, 4 096 токенов ввода/вывода.
  • Результаты пишутся в CSV и публикуются в PR как results-<platform>-<date>.md.

• Сравнение

  • Построить графики «токен/с vs. Watts» и «$/1k токенов vs. модель».
  • Выделить break-even точку, где кластер начинает выигрывать по стоимости при одновременной обработке ≥3 моделей.

• AMD Framework Desktop (AI Max+ 395) показывает 2,5–3× прирост к RTX 4000 SFF Ada 20 ГБ, но уступает 9950X из-за низкого TDP.
• Для локального запуска LLM рекомендуют RTX 3090 (24 ГБ) как лучшее ценовое решение, либо Apple/AMD при необходимости >20 ГБ памяти.
• ROCm и Linux-стек работают стабильно, но потенциал iGPU/NPU ещё не раскрыт; тесты велись в llama.cpp.
• Для масштабирования предлагают distributed-llama, Exo и llama.cpp-RPC, а также Oculink/eGPU-конфигурации.
• Продукт выглядит нишевым: ML-инференс дома, но для «обычных» задач лучше Threadripper или сервер.