Hacker News Digest

Автор перешёл на самохостинг после нескольких лет в Индии, где стриминговые сервисы стоили дёшево по западным меркам. Вернувшись, он не захотел платить западные цены и устал от «беговой дорожки вовлечённости» — особенно ради сына: постоянные «рекомендовано для вас» и «далее» мешали ограничивать контент. Отказ от стриминга в пользу Jellyfin за полтора года открыл дорогу к десяткам других сервисов и снизил зависимость от облачных провайдеров.

Правила просты: никакие сервисы, кроме VPN на роутере, не выставляются в публичный интернет — провайдер использует CGNAT для IPv4, а VPN доступен только по IPv6, из-за чего почти не работает в публичных сетях Wi-Fi. Предпочтение отдаётся нативному запуску, а не контейнерам: сервис из одного бинарника на Go — идеал, а требующий MySQL, Redis и ещё трёх контейнеров вызывает поиск альтернативы. Docker автор забросил в пользу Podman с его отличной интеграцией с systemd.

Итог: 17 нативных сервисов и 11 под управлением Podman, все через systemd. Мини-ПК Beelink S12 Pro на Intel N100 с 16 ГБ памяти держит около 7,5 ГБ занятой памяти и загрузку процессора 30–40%. Firefly III оказался слишком сложным, OwnTracks не смог стабильно сообщать позицию, а Music Assistant пытался «владеть» всей музыкальной конфигурацией. Самохостинг почты автор считает неоправданно трудоёмким.

Обсуждение дополняет статью практическими советами по железу, организации сети и спорами о выборе между легковесными бинарниками, Docker и Kubernetes. Спор: Пользователи спорят о ресурсоемкости *arr-стека: @eleventen и @eventuallyok утверждают, что Sonarr и Radarr потребляют минимум CPU и около 160 МБ RAM в простое; другие считают их сложными и хрупкими. Спор: Разногласия по базам данных: @mikeocool рекомендует SQLite для простоты селф-хостинга; @diebillionaires и @scottydelta предпочитают Postgres за его преимущества. Совет: Для бюджетного сервера @hypfer рекомендует б/у Intel NUC 8-го поколения (~110€); @bahmboo советует MacBook Air M1 с разбитым экраном как энергоэффективный headless-узел. Совет: Для доступа к сервисам без открытия портов в интернет @turtlebits рекомендует Pangolin; @jwrallie предлагает Tailscale + Samba. Совет: Вместо полного хостинга почты @ebrahimh советует использовать mbsync для зеркалирования входящих из Gmail/Proton в локальный фронтенд вроде Roundcube. Совет: Для управления музыкой @disposition2 рекомендует Lyrion как более современную и удобную альтернативу MPD для множества клиентов. Декларативное развертывание (Docker Compose, k3s/k8s) считается стандартом для минимизации ручной настройки и упрощения миграции между железом. Совет: По опыту @bengalister, Kubernetes для домашних сервисов может быть избыточным, но помогает поддерживать профессиональные навыки. Совет: Для синхронизации паролей @seplox рекомендует KeePass + Syncthing.

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‑файлов.

Процесс загрузки Linux начинается с нажатия кнопки питания, после чего процессор переходит в реальный режим (real mode) и выполняет инструкцию по адресу сброса 0xFFFFFFF0. Это приводит к запуску микропрограммы на материнской плате (BIOS или UEFI), которая выполняет самотестирование (POST) и ищет загрузочное устройство. При обнаружении загрузочного сектора (маркеры 0x55 и 0xAA), BIOS копирует его в память по адресу 0x7C00, после чего управление передается загрузчику GRUB. GRUB считывает свою конфигурацию, загружает ядро Linux в память и передает управление программе настройки, которая создает предсказуемую рабочую среду: выравнивает сегментные регистры, создает стек, очищает область BSS и запрашивает информацию о доступной памяти у микропрограммы. В конце концов, вызывается первая функция C с именем main, что标志着 переход к следующей фазе загрузки.

• Обсуждение показало, что статья о процессе загрузки Linux охватывает только самые базовые концепции, что вызвало критику за упрощение и упущение важных деталей, таких как взаимодействие с UEFI, инициализация видео и роль загрузчика.
• Участники подчеркнули, что статья не соответствует уровню подготовки аудитории Hacker News, и что она не раскрывает важные темы, такие как влияние UEFI на процесс загрузки.
• Также было отмечено, что статья не затрагивает такие важные темы, как влияние UEFI на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Некоторые комментаторы выразили сожаление по поводу того, что статья не затрагивает такие темы, как влияние systemd на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Также было отмечено, что статья не упоминает о таких важных компонентах, как initrd и драйверы, и не раскрывает влияние systemd на процесс загрузки.

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

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

Из-за отсутствия пространств имён или типов легко допустить ошибку, например, перезаписать критичную переменную PATH. Хотя они удобны для конфигурации, их следует использовать с осторожностью.

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

Переход с macOS на Arch Linux (Omarchy)

После 15 лет на MacBook Pro M1 Max я пересел на недорогой Lenovo ThinkBook 14 G7 с Omarchy — обвязкой над Arch Linux. Первый месяц использования (с перерывами на ремонт) и две полные недели — вот краткий итог.

Подготовка

Перед переходом проверил, что всё критичное доступно:

• Obsidian, fuzzy-файловый поиск, скриншоты, фото-редактор, f.lux, календарь в трее, гибернация.
• Единственное, что не решено — полный бэкап системы (Time Machine пока не нашёл аналога).

Что потерял и что приобрёл

• Скриншоты: Snagit пока не заменил; быстрый OCR и библиотека скринов отсутствуют.
• «Просто работает»: иногда ломаются шорткаты, но это цена свежести Omarchy и моей неопытности.
• Аккумулятор и шум: хуже, чем у M1, но принимаю за свободу настройки.
• Бэкап: пока ручной; после случайного слома /etc/sudoers понял, что нужен надёжный механизм.
• Синхронизация: Sync.com → Filen.io — безболезненно.

Omarchy

Omarchy — это Arch + готовые дотфайлы, Wayland (Hyprland), пакетный менеджер yay, и куча скриптов. Всё ставится одной командой, затем можно тонко под себя.

Опыт и выводы

• Аппарат: ThinkBook дешевле, но качество корпуса и экрана заметно хуже MacBook.
• Скорость работы: после настройки переключение между проектами стало мгновенным (Hyprland + workspaces).
• Обучение: за месяц освоил pacman, systemd, waybar, rofi, hyprland.conf — получил удовольствие от процесса.
• Следующий шаг: настроить полный образовый бэкап (Btrfs snapshots + rsync), чтобы не бояться экспериментов.

Итог: Linux требует времени, но даёт полный контроль и удовольствие от «собери сам».

• Пользователи хвалят «железо» Apple: трекпад, экраны, батарею, отсутствие шума вентиляторов и долговечность (5-13 лет).
• Многие жалуются на macOS: странная логика, невозможность мгновенного переключения рабочих столов, «мусор» вроде .DS_Store.
• Linux-энтузиасты ищут ноутбуки с ARM, хорошими драйверами, металлическим корпусом и большой батареей, но пока не находят идеального аналога MacBook.
• Omarchy (Arch-дистрибутив) упрощает установку Arch, но вызывает сомнения в долгосрочной поддержке.
• Часть разработчиков использует Mac как «красивый UNIX» и SSH-доступ к мощным Linux-серверам, чтобы совместить плюсы обеих систем.