Alpine Linux vs Gentoo

Ты можешь на основе gentoo собрать компактный дистрибутив, имеющий только нужное (как например было с Chrome OS или livecd дрвеба)
На основе alpine - уже не выйдет, потому что начнутся притягивания ненужных библиотек, а из сорцов он собирается не так гибко.
Конечно обычная gentoo с build environment'ом не бует компактной - ведь среда сборки много места занимает. Если тебе нужно именно собирать компактный дистрибутив и gentoo не устраивает - посмотри в сторону Yocto, OpenWRT и других embedded решений

В alpine используется musl.

Не помню, вроде бы в Gentoo тоже вместо glibc можно использовать другую библиотеку, вроде бы даже stage3 был другой.

Но если сравнивать Gentoo+Glibc и Alpine - последний будет компактнее.

Ты ещё не забывай, что в Gentoo ПО ставится так сказать в dev режиме, со всеми заголовочными файлами, библиотеками и прочими пакетами, нужными только для сборки, а не для запуска ПО.

Ну сделали бы профиль, который позволяет собирать в EROOT систему, более компактную чем Alpine, и вытеснили бы этот Alpine из докера. Это же важная коммерческая ниша, и влияет на пиар дистрибутива.

Бери сразу stage3 на musl и собирай.

• https://www.gentoo.org/downloads/amd64/#stages-advanced

Так что уже есть готовое.

Не уверен, что можно пересобрать систему, собранную на glibc на musl.

более компактную чем Alpine и вытеснили бы этот Alpine из докера

Не выйдет, для контейнеров и devops / cicd важна повторяемость окружения.

В случае Gentoo это как-то не очень возможно.

В случае Gentoo это как-то не очень возможно.

А в Guix есть повторяемость, но нет USE-флагов и минимизируемости…

В случае Gentoo это как-то не очень возможно.

Возможно, и реализуется абсолютно точно так же: через фиксированный базовый образ.

madpc ~ # eselect profile list|grep musl
  [44]  default/linux/amd64/23.0/musl (dev)
  [45]  default/linux/amd64/23.0/musl/systemd (dev)
  [46]  default/linux/amd64/23.0/musl/llvm (exp)
  [47]  default/linux/amd64/23.0/musl/llvm/systemd (exp)
  [48]  default/linux/amd64/23.0/musl/hardened (exp)
  [49]  default/linux/amd64/23.0/musl/hardened/systemd (exp)
  [50]  default/linux/amd64/23.0/musl/hardened/selinux (exp)
  [51]  default/linux/amd64/23.0/split-usr/musl (dev)
  [52]  default/linux/amd64/23.0/split-usr/musl/llvm (exp)
  [53]  default/linux/amd64/23.0/split-usr/musl/hardened (exp)
  [54]  default/linux/amd64/23.0/split-usr/musl/hardened/selinux (exp)

бери musl, кто мешает
только не понимаю, как именно это связано с компактностью
и откуда аксиома, что alpine компактнее

Ты ещё не забывай, что в Gentoo ПО ставится так сказать в dev режиме, со всеми заголовочными файлами, библиотеками и прочими пакетами, нужными только для сборки, а не для запуска ПО.

можно собирать нужное в отдельный от билд-системы dst, в крайнем случае потом ручками почистить /usr/include итп для готового образа но деталей сейчас не вспомню, и с тех пор многое могло стать проще

а ебилды, нужные только при сборке так и указаны в зависимостях, они автоматом могут быть вычищены при depclean

Так или иначе, мейнстрим - это Alpine. Она точно выживет, а Gentoo останется без контрибьюторов, когда они вымрут от возраста.

кек

Это произойдёт потому что не будет притока новых контрибьютеров из докера, все они уйдут в мейнтейнеры alpine linux.

не интересуюсь гороскопами

но изначальный наброс в теме непонятен
к чему вообще сравнение конструктора, из которого можно собрать что угодно, и узкоспециализированного дистрибутива?

Этот узкоспециализированный дистрибутив появился позднее Gentoo. И он собран не на основе Gentoo. То, что Gentoo не смогла перехватить инициативу и забороть это начинание, говорит о проблемах в генте.

И так у них всегда - то жалуются на недостаток мейнтейнеров, то ничего не делают, чтобы получить их приток.

из которого МОЖНО собрать что угодно

Ну вот, получилось, что прослойку для докера при помощи Gentoo собрать оказалось НЕЛЬЗЯ.
Не собирают через генту. Что-то значит мешает.

И так у них везде.

нихрена не понял
почему gentoo должен был решить выдуманную тобой проблему?
почему alpine должен был быть основан на gentoo, а какой-нибудь ubuntu не должен?
и почему что-то собрать НЕЛЬЗЯ?
для сборки софта для alpine используются какие-то другие волшебные компиляторы, аутомейки и прочее?

почему что-то собрать НЕЛЬЗЯ?

Это я и хотел бы выяснить в этой теме. Это её центральный вопрос.

Если что-то делается одним способом и не делается другим способом, значит для этого есть фундаментальная причина.

Иначе бы способ поменяли на более выгодный.

откуда вообще идея, что им мог бы понадобиться gentoo, но не смог?
авторам нужен был свой дистр со своей идеологией для решения своих задач, не зависящий от апстрима в виде генту или чего-то ещё
и у них свой набор патчей, релизы не роллинг и прочее

в alpine тоже далеко не все гладко, если что. Он может быть компактным из-за busybox, но у busybox все очень плохо с мейнтейнерами - их почти нет, а проблем накопилось много. Что с этим делать - непонятно.

Плюс в alpine проникли чудики на позиции ЛПРов.

Что с этим делать - непонятно.

Очевидно, же. ТС же ясно сванговал, что:

все они уйдут в мейнтейнеры alpine linux.

Нужно немного подождать и alpine расцветёт от избытка мейнтейнеров, кому не хватит хороших мест, будут вынуждены заниматься busybox'ом :)

бери musl, кто мешает

Там не только musl, там busybox вместо coreutils и пр. Чтобы такое стало возможным в gentoo, все скрипты нужно проверять/править на предмет совместимости...

Ну сделали бы профиль, который позволяет собирать в EROOT систему, более компактную чем Alpine, и вытеснили бы этот Alpine из докера. Это же важная коммерческая ниша, и влияет на пиар дистрибутива.

у генты нет цели, только путь. Коммерческие ниши её не интересуют.

Противоречие…

Разные принципы. Вы сравниваете уже готовую систему для целевых задач с конструктором, где цели ставит сам пользователь.

так нет никакой необходимости ломать какие-то скрипты генту, чтобы собирать говнообразы с бизибокс

А почему такой негатив к альпайну? Не нравится его идеология, что-то не работает? Никто же не заставляет им пользоваться.

Но большинство приняло его, и контейнеров на его основе куда больше, значит большинству это подходит.

Я бы тоже не хотел генту в контейнерах, слишком специфично и другая ниша у него.

Alpine Linux vs Gentoo

Вентилятор на аватарке

умудряются делать дистрибутивы меньшего размера.

имеется ввиду базовая часть системы без гуйни? по моим личным наблюдениям такой самый маленький дистр по размеру это дебиан, а по количеству пакетов арч.

И в этот образ можно было установить любой ebuild и будет работать? В logrotate-скриптах нет завязки на coreutis, на bash? В gentoo wiki настоятельно не рекомендуют удалять bash из системы.

Я не про «ломать», а по «чинить», чтобы скрипты корректно работали с busybox coreutils и ash. Это если пытаться делать урезаный, но gentoo, куда можно что-то доставить, пусть и из бинарных пакетов. А не как genkernel, который хоть и собирает initramfs-образ под gentoo, но свои скрипты сборки, свои патчи на исходники.

И в этот образ можно было установить любой ebuild и будет работать?

не любой, конечно, а совместимые с этими вашими недолибц, либо ищешь или сам рисуешь свои патчи

В logrotate-скриптах нет завязки на coreutis, на bash? В gentoo wiki настоятельно не рекомендуют удалять bash из системы.

так в целевой системе не нужно ничего этого
ведь задача создать минимально рабочую перделку для конкретного функционала, которую закатать в образ для докера, или там initrd
в нём самом не нужно ничего для сборки и прочего генту-ориентированного

так в целевой системе не нужно ничего этого

Я не знаю, что там нужно в целевой системе. Я про alpine и докер прочитал здесь: https://habr.com/ru/companies/digdes/articles/415279/ , там перечислили openrc, sshd, crond, ntpd, журналирование (текстовые логи), пакетный менеджер. Раз логи, значит logrotate.

с этими вашими недолибц

Каким «нашим», вы куда меня записали? Сами предложили собирать с musl.

там перечислили openrc, sshd, crond, ntpd, журналирование (текстовые логи), пакетный менеджер. Раз логи, значит logrotate.

не вижу проблем с перечисленным
кроме нюансов с пакетным менеджером - если он так нужен прям внутри образа, то я бы, например сделал для него через binpkg, которые собираются на хостовой системе
но держать там portage, даже без сборки, потянет как минимум бидон со всеми вытекающимися
но мы тут уже встали на не совсем верный путь «сделать как в алфине», тогда как в генту это может быть реализовано другими способами

Каким «нашим», вы куда меня записали? Сами предложили собирать с musl.

это ТС выставил требование musl, в gentoo для этого есть готовые профили
а uclibc вроде выпилили

ТС выставил требование musl

Неправда. Я просто просил сделать компактнее, чем в Alpine.

в генту это может быть реализовано другими способами

нужно, чтобы не просто было «можно», а чтобы ещё было удобнее

не существует абстрактной задачи «сделать как там, лучше чем там»
конкретизируй, что именно ты хочешь от итоговой сборки
и да, если ты хочешь там держать автономный полноценный portage и всё необходимое для сборки - то это уже не задача минималистичной системы, хотя и требуемые непосредственно для дела пакеты ты сможешь собирать с минимумом необходимых зависимостей

автономный полноценный portage

Вот мы и выявили фатальный недостаток Gentoo - это её пакетный менеджер.

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

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

Тут вопрос твоей полноценности как специалиста на первом плане. Если ты не читаешь документацию, а пользуешься ИИ или задаёшь вопросики на форуме, вместо чтения документации.

Пакетный менеждер должен называться p.
а команда установки должна быть i
p i <имя-пакета>

Это сэкономит байты. Обновление: p u

Рекомендация будет выполнять p u && p i <имя-пакета>,
сам дистрибутив можно будет назвать pupi linux (не puppy)

Вот кстати на счет компактной Gentoo, я давным давно как-то баловался и у меня даже получилось загрузиться в полученное поделие. А как с этим обстоят дела сейчас?

Какие методы, кроме указания абстрактной директории в качестве корня применимы на Gentoo, чтобы не тащить (или удалить, находясь в chroot) весь dev в том числе portage и gcc?

Можно конечно сделать:

emerge --depclean --with-bdeps=n -a
и потом все почикать ручками:
/usr/src/*
/usr/portage/*
/usr/share/doc/*
/usr/share/man/*
/usr/include/*
/var/cache/distfiles/*
/var/db/pkg/*

Но как-то это не спортивно и останется мертвый emerge.

Вот мы и выявили фатальный недостаток Gentoo - это её пакетный менеджер.

нет, гибкость portage - главное достоинство gentoo

Надо, значит, делать новый пакетный менеджер, модульный,

кому надо, зачем?

по крайней мере с двумя частями - для эксплуатации и для полноценности.

если я правильно тебя распарсил, для первого есть binpkg

делоешь

ROOT="${MYROOT}" emerge -1 baselayout

tar -C "${MYROOT}" -cf - . | docker import - my-mini-mega-cool-gentoo

Но как-то это не спортивно и останется мертвый emerge.

тут шашечки или ехать
для binpkg он мёртвым не будет, если не чистить

/var/db/pkg/*

ну и момент, если тебе хочется собрать мусл на хосте с православной глибц, то надо будет развернуть соответствующий stage3 и делать всё перечисленное из его цшрута, как самое простое
либо использовать sys-devel/crossdev, что менее костыльно, но, возможно, менее интуитивно понятно с непривычки
зато будет возможность собирать даже под другие архитектуры

если не чистить

Зачем вообще хранить базу инсталлированных пакетов?
Вон, в оффтопике каждый инсталлятор умеет удалять программу, и ничего лишнего на диске не скапливается.

А чтобы зависимости посчитать - пусть скачивает инсталляторы, а они пусть проверяют, готовы ли они установиться.

Зачем вообще хранить базу инсталлированных пакетов?

там хранится информация об установленных пакетах

Если информацию об установленных пакетах не хранить, финальная установка меньше места будет занимать. Как не хранить - я уже описал.

«пакетный менеджер APK, который хранит информацию об установленных пакетах в нескольких местах на диске. Основные из них: /etc/apk/world (список явно установленных пакетов), кэш APK (обычно /var/cache/apk/), а также база данных APK (вероятно, в /var/lib/apk/ или аналогичном).»
Если так не делать, то можно обогнать Alpine по компактности.

Если информацию об установленных пакетах не хранить, фильнальная установка меньше места будет занимать.

там на каждый пакет от пары килобайт до... ну вот, у gcc 300, например

Вон, в оффтопике каждый инсталлятор умеет удалять программу, и ничего лишнего на диске не скапливается.

в оффтопике давно пакетная система с зависимостями?
честно говоря, уже утомили твои неграмотные набросы

пакетная система с зависимостями?

Наличие или отсутствие зависимостей там не важно. Но вообще-то зависимости там (в .msi) есть, просто их (несколько .msi) надо все вместе распространять. Но и то это не всегда так (системные пакеты ставятся отдельно, приложения отдельно).

В дистрибутиве тоже все пакеты распространяются вместе.

твои неграмотные набросы

Безосновательное обвинение. Лично мне мои идеи нравится.

Лично мне мои идеи нравится.

Что мешает их реализовать? Соберите генту а-ля альпайн, будет интересно посмотреть различия в компактности.

Что мешает их реализовать?

Это не единственные мои идеи. У меня ещё много других, более безумных, которые я реализовываю тайно, в промежутках между короткими перебежками.

По идее, у Gentoo выше потенциал быть компактным дистрибутивом, чем у Alpine Linux.

С обвязкай на Python и набором компиляторов? (%

Вон, в оффтопике каждый инсталлятор умеет удалять программу, и ничего лишнего на диске не скапливается.

Гм, см. https://learn.microsoft.com/en-us/troubleshoot/windows-client/application-man...

The Windows Installer Cache is used to store important files for applications that are installed by using Windows Installer. By default, this cache is located in the c:\windows\installer folder, and it should not be deleted. If the installer cache is compromised, you may not immediately see problems until you take an action such as uninstalling, repairing, or updating a product.

When a product is installed by using the Windows Installer, important files are stored in the Windows Installer cache that are required for uninstalling and updating applications. Missing files cannot be copied between computers because the files are unique.

А база инсталлированных MSI хранится в реестре.

зырьте, до чего дошёл прогресс

# export MYROOT="/home/chr/gm"
# mkdir -p ${MYROOT}
# crossdev -S -t x86_64-pc-linux-musl
...
# USE="build" ROOT="${MYROOT}" PORTAGE_CONFIGROOT="${MYROOT}" x86_64-pc-linux-musl-emerge sys-apps/baselayout
...
# USE="-pam static make-symlinks" ROOT="${MYROOT}" PORTAGE_CONFIGROOT="${MYROOT}" x86_64-pc-linux-musl-emerge sys-apps/busybox
...
# du -scxh ${MYROOT}/*
0       /home/chr/gm/bin
3,5K    /home/chr/gm/boot
3,5K    /home/chr/gm/dev
156K    /home/chr/gm/etc
3,5K    /home/chr/gm/home
0       /home/chr/gm/lib
0       /home/chr/gm/lib64
0       /home/chr/gm/libx32
3,5K    /home/chr/gm/media
3,5K    /home/chr/gm/mnt
3,5K    /home/chr/gm/opt
3,5K    /home/chr/gm/proc
4,0K    /home/chr/gm/root
3,5K    /home/chr/gm/run
0       /home/chr/gm/sbin
3,5K    /home/chr/gm/sys
3,5K    /home/chr/gm/tmp
1,3M    /home/chr/gm/usr
163K    /home/chr/gm/var
1,7M    итого

# chroot /home/chr/gm/ /bin/sh

/ # ls
bin     dev     home    lib64   media   opt     root    sbin    tmp     var
boot    etc     lib     libx32  mnt     proc    run     sys     usr

/ # sh --help
BusyBox v1.36.1 (2026-04-17 16:06:04 MSK) multi-call binary.

Usage: sh [-il] [-|+Cabefmnuvx] [-|+o OPT]... [-c 'SCRIPT' [ARG0 ARGS] | FILE ARGS | -s ARGS]

Unix shell interpreter

Вот когда бо́льшая часть контейнеров в репозитории докера станет на генте, тогда поверю.

А сейчас этому явно что-то мешает.

а когда генту позиционировался как дистр для вайб хомячья с докерами?
он всегда был для тех, кто знает, чего хочет и разбирается в этом