Comments 12
Yocto можно было бы рассмотреть .
Arch , OpenBsd , buildroot :)?
Кажется будто большая часть статьи написана иишкой - читать отбивает желание(
musl libc: <..> спроектирована с упором на безопасность и корректность.
afaik задача была сделать так, чтобы генерировалось меньше кода и можно было статически компилировать для использования во встраиваемых системах, а не про безопасность-корректность. Багов, UB и просто неработающих API там емнип не меньше, чем аналогичных проблем в том же glibc.
Tiny Core Linux
за новое имя спасибо. интересно насколько реально его в какой-нибудь докер запихнуть
Удивительно конечно, что arch не оказалось в списке, хотя казалось бы rolling release, безопасность и вот это вот всё.
Странно )), но deepseek по заголовку и некоторым ключевым словам выдал почти идентичный текст, включая таблицы.
На Хабре теперь все статьи так пишутся?
Рач Линупс и Гента:
*Просто существуют*
Какой текст, такие комменты :) :
Почему Fedora CoreOS / Flatcar — плохая идея как base image
❌ Они не для этого созданы
Fedora CoreOS и Flatcar:
immutable OS
управляются через Ignition / Butane
обновляются атомарно
не имеют нормального userland для приложений
В контейнере это означает:
нет привычного package manager
нет стандартной иерархии для runtime-софта
сложная отладка
огромный размер образа
❌ Контейнеры ≠ виртуальные машины
Использовать CoreOS/Flatcar как base image — это попытка:
“запихнуть VM-подход внутрь контейнера”
Это анти-паттерн.
Контейнер:
должен содержать только приложение и его зависимости
не должен управлять systemd, users, kernel-настройками
❌ Нет выигрыша по безопасности
Иногда аргумент звучит так:
“Flatcar безопаснее, значит и контейнер будет безопаснее”
На практике:
attack surface больше, чем у distroless
CVE-сканеры будут ругаться сильнее
SBOM и SLSA страдают
Минималистичные дистрибутивы Linux: как выбрать систему, которая не подведет