Hacker News Digest

Процесс загрузки 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 системах.

Проект 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).

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

PDF-1.2, 8191 объект, линеаризован, 598 xref-записей.  
Содержит структуру документа (каталог, страницы, шрифты, потоки), но без текста.  
Все данные — служебные, читаемого контента нет.

• Книга «The Unix-Haters Handbook» вызывает смешанные чувства: кто-то видит в ней ценный исторический артефакт и живую критику, кто-то — просто троллинг.
• Участники вспоминают конкретные «болячки» Unix: sendmail, csh, права доступа, «всё есть файл», который не всегда работает.
• Многие признают, что за 30 лет часть проблем решена, но новые появились — например, systemd, который теперь вызывает аналогичную ненависть.
• Любовь к Unix всё же сохраняется: дёшевые процессы, пайпы и «всё есть текст» делают систему удобной, особенно с помощью современных ИИ-ассистентов.
• В дискуссии всплыли ностальгия по Lisp-машинам, шутки про EMACS, барф-баг в комплекте книги и даже возможный «systemd haters handbook».

Для сборки 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.

Переход с 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-серверам, чтобы совместить плюсы обеих систем.

Запускаю полноценный Linux-десктоп в Docker — просто потому что могу

Автор: Ali Haider

Docker считается исключительно для CLI-сервисов, но я решил разместить в контейнере полноценный графический Linux. Зачем? Из чистого любопытства и желания проверить границы технологии.

Почему не VirtualBox или dual-boot?
Хотелось получить Linux, который живёт рядом с Windows без перезагрузок и разделов. Казалось, что за пару дней подниму GNOME/KDE в контейнере, но эксперимент затянулся на четыре дня и превзошёл все ожидания.

Что получилось
На Windows 10 через Docker удалось запустить полноценный рабочий стол. Проект стал жёстким crash-курсом по X11, PulseAudio, GPU-пасsthrough и сетевым трюкам, но в итоге всё работает: окна Linux-приложений появляются поверх Windows, звук идёт, файлы доступны.

• Участники делятся опытом запуска полноценных Linux-десктопов в Docker/LXC: Arch + noVNC, Selkies + KDE, linuxserver/webtop, SkiffOS.
• Обсуждают производительность: 70 % от нативной при web-VNC, лучше через Sunshine или xrdp с аппаратным ускорением.
• Появляются идеи: эфемерные браузеры через Tailscale+Mullvad, Twitch/Discord-Plays-Pokemon, тесты из разных стран.
• Кто-то предпочитает LXC/LXD или systemd-nspawn, чтобы не мучиться с systemd внутри OCI-контейнеров.
• Вспоминают исторические проекты: Jess Frazelle, Samsung DeX, WSL2 + MobaXterm, MATLAB-контейнер.

systemd-харднинг: кратко и по делу

sudo systemd-analyze security показывает «красную» таблицу рисков.
sudo systemd-analyze security имя.service — детально по конкретному юниту.

Колонка Exposure — главный ориентир: чем выше значение, тем больше прав можно отнять.

Как править

1. sudo systemctl edit имя.service создаст override-файл.
2. Параметры пишутся в секции [Service] (или [Container] для quadlet).
3. Сервис не стартует — значит убрал нужное, возвращай.

Часто используемые директивы

Директива	Что делает
NoNewPrivileges=true	запрет setuid/setgid
PrivateTmp=true	изолированный /tmp
ProtectSystem=strict	корень только read-only
ProtectHome=true	/home, /root недоступны
ReadWritePaths=/var/lib/app	белый список для записи
CapabilityBoundingSet=CAP_NET_BIND_SERVICE	только нужные capability
SystemCallFilter=@system-service	разрешённый набор сисколлов
RestrictAddressFamilies=AF_INET AF_INET6	только нужные семейства сокетов
MemoryDenyWriteExecute=true	блок W^X
LockPersonality=true	запрет смены personality()
RestrictRealtime=true	нельзя захватывать realtime-приоритеты
UMask=0077	файлы создаются 600
RemoveIPC=true	чистит SysV IPC при выходе

Пример override

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/myapp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
SystemCallFilter=@system-service
RestrictAddressFamilies=AF_INET AF_INET6
MemoryDenyWriteExecute=true
LockPersonality=true
RestrictRealtime=true
UMask=0077
RemoveIPC=true

Проверь: sudo systemctl daemon-reload && sudo systemctl restart имя.service.

Это не серебряная пуля; подгоняй под каждый сервис и смотри логи.

• Предложена утилита shh, которая по логам strace автоматически подбирает параметры hardening для systemd-сервисов.
• Комментаторы отмечают, что дистрибутивы не включают жёсткие настройки по умолчанию: боятся сломать edge-case’ы и получить поток баг-репортов.
• Обсуждается идея общего репозитория с готовыми «жёсткими» unit-файлами для популярных сервисов.
• Утилита systemd-analyze security и встроенный механизм credentials systemd названы полезными инструментами повышения безопасности.
• Несколько человек поправили: правильное написание — «systemd», а не «SystemD».