Gentoo анонсировали бинарную сборку gentoo-kernel-bin

Если бы у генты были централизованые бинарные пакеты

Если бы у бабушки был йух, она бы была дедушкой (т.е. дебильяном)

Под этими словами нет никаких оснований

Меня не пугают длинные логи и компиляция, это мой локалхост и мое личное время. Я уже пару раз поднимал генту на виртуалке, вопрос лишь в том, чтобы как-нибудь выбрать время и удобно перенести систему с арча на генту. С этим сложнее.

Это очередной раз подтверждает то, что админам локалхоста и адептам конпелирования на локалхосте принципиально пофиг, что в стейбл прилетает неработающая версия пакета. И в целом работает ли это или не работает. Этж локалхост

А вот людям, которые работают, то, что неработающая версия пакета прилетела в стейбл, наводит мысли о том, что технологический процесс в этом дистрибутиве не подходит для работы. Берут и удаляют его. И пользуются чем-то другим(и это далеко не "божественный арч(или рач, как правильно?)

Ставится ядро и делается make localmodconfig и задачка решена.

Интересно, что изменится в Calculate-linux?

Эти бинарные пакеты надо будет собирать минимум в 2^n экземплярах (по количеству use-флагов), а без флагов гента превращается в дебиан.

Или что у тебя подразумевалось?

Архитектурно дебиан в подмётки не годится генте

Она нужна для USE флагов. Мы просто не настолько модуляризируем софт через рантайм плагины чтобы они поддерживались без перекомпиляции

Ты просто тупое чмо! Хера ты тут выступил? Лошара тупой. Мозга нет, чтобы понять? Пишет он, работяга.

Gentoo был заточен под определенный круг задач, а теперь прогнулся. SystemD есть, binary kernel - жрите. НА хера тогда оно надо? Я с таким успехом могу контейнер воткнуть с любой версией программы.

Просто тупое не догоняет, не будет Gentoo - будет 2 дистра (а потом 1).

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

Чем мне нравится gentoo-sources, можно лишнее выкинуть, что существенно сократит время его сборки. Но вещь полезная в любом случае, особенно для быстрого развёртывания.

С чисто технической стороны сделать бинарники собранные с разными USE-флагами - вполне реально. Только тут всплывает вторая архитектурная промашка Getntoo - rolling release. При этом этот роллинг настолько роллинг, что версии пакетов апаются бездумно и в большом кол-ве. Для бинарей всех версий с разными флагами нужно много места. Очень много. И гентушникам не объяснишь, что если версию 1.2.1 апать на версию 1.2.2 –> 1.2.3,…,1.3.6 бессмысленно, т.к они функционально идеинтичны. И что апрувить ап версий надо с умом, когда в версии 1.3.6 действительно появилось что-то архинужное. Но это за пределом понимания. В дебиане не зря сделали релизы. И версии пакетов там апаются, но в пределах одной мажорной версии и только тогда, когда это реально нужно. И только тогда, когда это оттестировано. В генте же у меня были проблемы и с nvidia-drivers. Когда в стабильной ветке пакет не собирается, а в ~amd64 он работает. Сейчас функционал программ уже написан. Версия 1.2.3 и 1.3.6 ничем не отличаются. А версия 2.0.1 тоже такая же, но там внутри косметику кода сделали и новый формат конфигов прикрутили. Так вот в генте все эти пакеты апаются и на другую мажорную версию. И если у тебя 1.5к пакетов, то в течение года у тебя все эти 1.5к пакетов меняют и минорные версии, попутно ломаясь и отпадая, так еще и меняют мажорные версии, что приводит к тому, что только тем и занимаешься, что чинишь конфиги. При этом функционально оно не меняется по юзабилити

Заспорим, что gentoo-kernel-bin работает так же, как твоё собранное gentoo-sources. И ставится быстрее. И в эксплуатации проще. И что компилировать gentoo-sources не имеет никакого практического смысла

Я о том же, что если дебиановцам что-то в голову стукнет(а уже стукнуло), то бежать будет некуда. Куда сейчас бежать? В CRUX? В коммерческий загнувшийся коммерческий проект Патрика без пакетного менеджера slackware? В Gentoo, в котором сейчас 3.5 колеки и 286 конпеляторов и в котором всё отваливается 129 раз в месяц, которое невозможно не локально держать, не на сервер поставить? Если генту не починят архитектурно и не сделают там бинарные пакеты, чтобы всё работало, бежать придётся на freeBSD. А вот очень не хочется.

Gentoo был заточен под определенный круг задач

Генту должна быть гибкой функциональной стабильной, а не заточеной под определенный круг задач, балбес. Иначе ее будет юзать 3.5 колеки под этот определенный круг задач

Просто тупое не догоняет, не будет Gentoo - будет 2 дистра (а потом 1).

Ха-ха-ха, проснулся. Уже сейчас 2 дистра

1. rhel и дочка centos
2. debian, а всё остальное базируется на дебиане

А остальные дистрибутивы в разной степени наркоманские и неюзабельные

Да я понимаю что много лишнего и неоптимизировано и т.д но не факт что этих бинах не также, опять же зачем бины то раздавать ? раздавали бы просто конфиги под них …

Возможно, так проще в отладке юзеропроблем. Когда юзер грузил конкретный бинарник - это один момент. Когда же юзерам выдали стандартные конфиги, а они их и подкорректировать могли и разные флаги сборки использовать - совсем другой.

Что ещё остались гентушники в русских селениях?

Открою для тебя небольшой секрет. На лайвсиди выполняешь zcat /proc/config.gz и получаешь этот самый конфиг. Его раздают со дня появления первого лайвсиди

Я в курсе, что так можно текущий конфиг получить. То есть и с лайф сиди и даже в рабочем ядре включить поддержку этого и твой конфиг всегда будет в /proc. А ключи сборки? Плюс разные версии компилятора могут собрать немного по-разному.

Ловить баги незнамо где?

оно ничего не собирается. Тот же mpv +vulkan.

emerge --info mpv

media-video/mpv-0.32.0-r1::gentoo was built with the following:
USE="X alsa cdda cli dvd egl iconv jpeg libass libmpv lua openal opengl pulseaudio samba sdl uchardet vaapi vdpau vulkan xv zlib (-aqua) -archive -bluray (-coreaudio) -cplugins (-cuda) -debug -doc -drm -dvb -gamepad -gbm -jack -javascript -lcms -libcaca -luajit -oss (-raspberry-pi) -rubberband (-selinux) -test -tools -wayland -zimg" ABI_X86="(64)" PYTHON_TARGETS="python3_7 -python3_6 -python3_8"
FEATURES="protect-owned userfetch usersandbox preserve-libs sfperms unmerge-orphans unmerge-logs distlocks strict unknown-features-warn qa-unresolved-soname-deps binpkg-docompress buildpkg fixlafiles assume-digests binpkg-dostrip binpkg-logs ipc-sandbox network-sandbox ccache ebuild-locks parallel-fetch config-protect-if-modified sandbox merge-sync multilib-strict parallel-install pid-sandbox usersync xattr

Все собирается не надо нам врать.

А ключи сборки?

make -j nproc вот тебе и все ключи сборки

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

не используй компилятор от MS и gcc будет тебе собирать всегда одинаково xD

Тебе что видео записать?

Зачем мне видео ? Просто признай что ты неосилятор и балабол.

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

Что-то такое я переживал, когда увидел магазин одежды для панков, на закате человечества.

На видяшку. 3.6метра https://www.sendspace.com/file/3q4u1l

Скоро calculate станет мейнстримом. Оно, пожалуй, и правильно.

Конпеляторам и предъявить нечего Gentoo. Они-то gentoo-sources оставили. Кто хочет конпелировать - может так же конпелировать :). Конпеляторы пока что еще не могут отойти от шока. Они в замешательстве. Я могу им подсказать: gentoo-sources рядом лежит с gentoo-kernel-bin. Он пропитывается этой бинарной нечистью, прям чувствуется, что когда скомпелировал gentoo-sources, что вроде работает, но! Но! Что-то не то! Что-то не так! И производительность упала на 0.00001% Это прям чувствуется

Это слив, ящитаю :) Но ты продолжай шутить, интересно же как далеко можно зайти отрицая очевидное.

у меня X в make.conf глобально, поэтому видимо проблем не возникло.

Сборка ядра из сорсов не имеет никакого смысла с 2010 года. Точно так же, как и компилировать монолитное ядро. Это уже обговорено 2020к раз. Всё нужное давно есть в ядре. И планировщики и поддержка нужных фс и многое другое. У дебиана ядро собрано так, что его не нужно пересобирать. Оно просто работает.

Нет имеет. Мне не нужен ынтырпрайз в ядре, всякая периферия для различных ноутов (ее навалом, см. x86-specific drivers в Device Drivers секции, или как-то так) зато я хочу поиграться с планировщиками tcp, i/o, на ноуте - LUKS2 (хотя да, возможно это уже включено).

Ты брось это про гибкий тулкит и всё такое. Оно не работает - это первое. Толку от наличия гибкости, если оно ничего не собирается. Тот же mpv +vulkan. Я вторю: если заморозить всё что есть в портаже и начать его тестировать, - то там 1/3 с разными флагами не собирается. Оно не рабочее. И по мере эксплуатации отваливается то голова, то хвост. Использовать это в проде и как девелоп станцию - невозможно

Ты выше написал, что у тебя с определенными флагами не компилилось. У меня компилиллось, т.к. X включен был глобально. Не компилится? пишешь багрепорт, чтобы майнтейнер поставил нужный флаг в required для зависимого пакета для mpv.

За счёт чего она получается быстрая и отзывчивая? Быстрота и отзывчивость не зависят от того, с поддержкой каких библиотек собран тот или иной пакет. Это КРИВДА.

Лет 5 назад тут проскакивал скриптик, который openssl-ем тестил производительность проца. Так вот, дефолтный Debian x86_64 выдал на 10-15% меньше производительность, чем та же самособранная гента. (в численном значении там было что-то вроде ~170k и 190k очков). Тред есть на ЛОРе, влом искать.

Давно хочу пересесть на генту, чтобы не видеть этой горы мусора в пакетах.

Он иногда и тут проскакивает, но значительно реже.

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

гента в проде неприменима +100500

Но ни на основной рабочей машине, ни на домашней лучше ничего для себя не представляю. И дело не в компиляции, а в удобстве накладывания [нужных мне] заплаток на существующие пакеты, создания своих и сохранения выброшенных из апстрима.

хм, неплохо, навряд ли я этим воспользуюсь, вопросик под шумок): сейчас пакет media-libs/mesa обновился до версии 20.1.7,

• Messages for package media-libs/mesa-20.1.7:
• CONFIG_CHECKPOINT_RESTORE: is not set when it should be.
• Please check to make sure these options are set correctly.
• Failure to do so may cause unexpected problems.

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

Заспорим

И там есть все нужные мне драйвера для моего wifi и внешней звуковой карты? Я и без споров попробую его как-нибудь.

cat /etc/portage/make.conf |grep -i use

# NOTE: This stage was built with the bindist Use flag enabled
USE="X pulseaudio"

out:

>>>  '/var/tmp/portage/media-video/mpv-0.32.0-r1/temp/build.log'

 * Messages for package media-video/mpv-0.32.0-r1:

 * ERROR: media-video/mpv-0.32.0-r1::gentoo failed (compile phase):
 *   build failed
 *
 * Call stack:
 *     ebuild.sh, line  125:  Called src_compile
 *   environment, line 4267:  Called waf-utils_src_compile
 *   environment, line 5281:  Called die
 * The specific snippet of code:
 *       "${WAF_BINARY}" ${_mywafconfig} ${jobs} "${@}" || die "build failed"
 *
 * If you need support, post the output of `emerge --info '=media-video/mpv-0.32.0-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=media-video/mpv-0.32.0-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/media-video/mpv-0.32.0-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/media-video/mpv-0.32.0-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/media-video/mpv-0.32.0-r1/work/mpv-0.32.0'
 * S: '/var/tmp/portage/media-video/mpv-0.32.0-r1/work/mpv-0.32.0'

кусок лога:

16:07:26 runner ['x86_64-pc-linux-gnu-gcc', '-O2', '-pipe', '-Wl,-O1', '-Wl,--as-needed', '-Wl,-z,noexecstack', '-pthread', 'osdep/main-fn-unix.c.21.o', 'audio/aframe.c.20.o', 'audio/audio_buffer.c.20.o', 'au>
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: video/out/vulkan/context_xlib.c.20.o: in function `xlib_init':
context_xlib.c:(.text+0x134): undefined reference to `vkCreateXlibSurfaceKHR'
collect2: error: ld returned 1 exit status

Waf: Leaving directory `/var/tmp/portage/media-video/mpv-0.32.0-r1/work/mpv-0.32.0/build'
Build failed
 -> task in 'mpv' failed with exit status 1:
        {task 140080620248272: cprogram main-fn-unix.c.21.o,aframe.c.20.o,audio_buffer.c.20.o,chmap.c.20.o,chmap_sel.c.20.o,ad_lavc.c.20.o,ad_spdif.c.20.o,af_format.c.20.o,af_lavcac3enc.c.20.o,af_scaletempo.c>
['x86_64-pc-linux-gnu-gcc', '-O2', '-pipe', '-Wl,-O1', '-Wl,--as-needed', '-Wl,-z,noexecstack', '-pthread', 'osdep/main-fn-unix.c.21.o', 'audio/aframe.c.20.o', 'audio/audio_buffer.c.20.o', 'audio/chmap.c.20.o>
 ^[[31;01m*^[[0m ERROR: media-video/mpv-0.32.0-r1::gentoo failed (compile phase):
 ^[[31;01m*^[[0m   build failed
 ^[[31;01m*^[[0m
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m     ebuild.sh, line  125:  Called src_compile
 ^[[31;01m*^[[0m   environment, line 4267:  Called waf-utils_src_compile
 ^[[31;01m*^[[0m   environment, line 5281:  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m "${WAF_BINARY}" ${_mywafconfig} ${jobs} "${@}" || die "build failed"
 ^[[31;01m*^[[0m
 ^[[31;01m*^[[0m If you need support, post the output of `emerge --info '=media-video/mpv-0.32.0-r1::gentoo'`,
 ^[[31;01m*^[[0m the complete build log and the output of `emerge -pqv '=media-video/mpv-0.32.0-r1::gentoo'`.
 ^[[31;01m*^[[0m The complete build log is located at '/var/tmp/portage/media-video/mpv-0.32.0-r1/temp/build.log'.
 ^[[31;01m*^[[0m The ebuild environment file is located at '/var/tmp/portage/media-video/mpv-0.32.0-r1/temp/environment'.
 ^[[31;01m*^[[0m Working directory: '/var/tmp/portage/media-video/mpv-0.32.0-r1/work/mpv-0.32.0'
 ^[[31;01m*^[[0m S: '/var/tmp/portage/media-video/mpv-0.32.0-r1/work/mpv-0.32.0'

Это стейбл, ага. В прод, срочно в прод!

Heresy!

Еще раз: где багрепорт?

Я за 9 лет неоднократно видел некомпилящиеся пакеты, которые были помечены как стабильные. И? Это процесс разработки, он не исключает таких вот нюансов.

Архитектурно дебиан в подмётки не годится генте.

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

Нет, собирается без genkernel. А для initramfs (которым я почти нигде не пользуюсь) тащит dracut.

И кому может понадобиться бинарное ядро, на котором не работает докер?

Сборка ядра из сорсов не имеет никакого смысла с 2010 года.

Это точно. Прям в ночь с 31 декабря на 1 января 2010 смысл был потерян.

Да есть же! Есть. 9 лет в стейбле появляются бажные пакеты. Если они там появляются 9 лет - что это означает? Мммм, а чёйта люди все разбежались из генты? Неееее, не из-за этого конечно же

Если бы у генты были централизованые бинарные пакеты

...то она была бы никсосью.

Прикинь, да. По-популярней, чем сейчас. Хотя никсось - еще та поделка. Но спуфингу нравится xD

либо пользовательской конфигурацией

пока не искал подробностей, но кто-нибудь уже выяснил где эту конфигурацию хранить?

И насколько они эффективны эти принципиальные различия? Я как вижу, Gentoo, - это грааль эффективности и эффективных решений. Именно поэтому генту - это практически стандарт в проде. Сарказм естественно

USE +savedconfig, затем в /etc/portage/savedconfig/sys-kernel/gentoo-kernel с опциональным суффиксом версии. По тому же принципу, как для busybox, linux-firmware.

Я утверждаю, что если в Gentoo отключить perdoling release, сделать централизованную систему бинарных пакетов с use-флагами(пусть даже с generic cflags), тщательно тестировать пакеты, которые лежат в стейбле, то в Gentoo придут и люди и инвестиции. И через пару лет Gentoo сильно потеснит debian. А через 3-4 года дебиану будет CRUX

Некоторые вещи сломаны by design и их невозможно починить. Сборка системы из исходников при полном отсутствии воспроизводимости окружения является примером подобного.
В никсе проблема сломаных пакетов решается банально CI'ем, в генте же она в принципе нерешаема.

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

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