Кто пробовал бинарные пакеты в Gentoo?

Вас тут 3,5 калеки.

Зоцени отэто - https://www.gentoo.org/news/2024/02/04/x86-64-v3.html

У меня,конечно, v4, но ты вообще на x86-64 и твой комп не знает, что у него есть. Иди, куда шел!

Нормально всё. Отличий между ебилдами и бинарными пакетами вообще нет, если версия glibc актуальная. Если USE-флаги не совпадают, то пойдёт сборка через ебилд, если совпадают — поставится бинарный пакет. Единственное что у портежа есть дебильная повадка лезть на бинхосты обновлять индекс при каждом запуске emerge, что приводит к тормозам на старте.

O kak. Spasibo.

А зачем? llvm/clang лучше собирать под железо

LLVM, CLANG и похожие

Эти бинарные не держу, из похожих только ржавка.
Из непохожих (как ни странно) ядро и (ожидаемо) ангуглед-хромой, файрфокс. Либерный офис собираю, поскольку -bin тянет какой-то неприятный набор устаревших зависимостей.

Там nomultilib только, емнип :(

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

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

Так, спасибо. Весь сыр-бор из-за avx512? Какой софт это использует? Беглый осмотр выдает пруф с играми, то такое. Тут и без этого просто за счет поколений эффективность выше, ну пусть будет. И все?

libreoffice-bin, firefox-bin считается? Тогда я пробовал, полёт нормальный.

Но если бинарными будет значительная часть пакетов - зачем тогда Генту? Тогда это Debian, вы ошиблись дверью.

Каждый инструмент под свои задачи.

Тогда это Debian

Дебиан собирают для копролитов из начала нулевых и для этого отключают всё что выше SSE2.

Тогда это Debian

Дебиан собирают для копролитов из начала нулевых и для этого отключают всё что выше SSE2.

А ты думаешь что в бинарных пакетах Генту по-другому?

Интересно, на этом бинхосте как собраны пакеты? Под какой march? Какой-то минимальный, чтобы всем подходило, или под несколько разных, и выбирается максимально подходящий под клиента?

я смотрю, читать не умеем. Выше дал ссылку, что сейчас есть пакеты, поддерживающие v3.
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
https://www.gentoo.org/news/2024/02/04/x86-64-v3.html

Теперь к ламеру - Kroz. Ты уже давно не у дел. Про флаги компиляции ты ноль без палочки. Всякие Clang, LLVM, lld/mold, Rust, GCC 12x…

Теперь про

Но если бинарными будет значительная часть пакетов - зачем тогда Генту?

Тем, что я использую конкретные программы, а не собираю ради обогрева помещения. Если компиляторы в Gentoo пошли по пути «всё включено», то смысл телодвижений? Приоритет USE flags. Раньше был rust-bin, теперь у меня и остальной хоровод. Так как не надо собирать, то я не танцую с Gentoo. Игнорируются LLVM_TARGETS

Да тебе не понять, ты же на полном серьёзе вот это пишешь

А ты думаешь что в бинарных пакетах Генту по-другому?

был бы ты в теме (а гентушники подглядели это дело у создателя на Funtoo), то знал бы различия, лошпед.

Да, это талант: написать так много слов, а по сути ничего не сказать, да ещё и параллельно испортить воздух.

Расскажи мне, о гуру, как сочитаются «USE flags» и «не надо собирать»?

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

Смотри, llvm и clang это как раз то что ты хочешь максимально быстро чтоб работало, со всеми оптимизациями которые твой процессор может (ещё ffmpeg если видео конвертируешь). Вот браузер, наверное, можно и бинарный накатывать.

Нет там никаких возможностей для пересборки. Или очень нетривиально. ИМХО, лучше затюнить флаги компиляторов GO, Rust, GCC, LLVM/Clang для сборки ПО.

Возьмём пример. -PIE. Ну с танцами мы его снесли, нам ASLR не упал. Только некоторые программы не собираются с флагом -no-pie. Особенно последние версии компиляторов знают «как лучше». Пацаны применяют магию смотрят сгенерированный код на ассемблере и говорят, что код говно удаление опции не спасат. И правильнее придушить канарейку -fno-stack-protection, толку больше. Опции меняются, меняется поведение, меняется код.

С моей конфой надо пересобирать только Gcc с включением jit, чтобы Emacs мог в elc. Остальные компиляторы пошли, как Горски наколдовал, бинарными и с поддержкой большинства архитектур. Когда ему начали по голове стучать о потере гибкости, он высказал мысль, что «это нужно трём калекам, в наше время халявных тактов/места/памяти, etc». Как истинный ЛОРовец новой волны.

Если поделиться опытом, что можно сказать… Установка Gentoo стала ещё более примитивнее, быстрее, удобнее. Я потратил времени в три раза меньше на установку. При этом многое пришлось настраивать с нуля. Дольше всего потрачено времени на поиск нормальной темы GTK3/4 и оптимизации компиляторов. Сейчас уже всё собирается всем и с разными настройками оптимизации. env вырос. Каждый пакет, который интересовал прописан отдельно, вплоть до MAKEOPTS=1 с LTO или без, Clang или GCC, Rust со своими RUSTFLAGS, а это заняло время на прочтения форумов и отзывов нормальных пользователей Gentoo. И Gentoo Wiki после НГ слегка поправили.

Столкнулся с неприятным поведением systemбуээ. С его понтами «работы из коробки», которая на проверку не работает. Можно с уверенностью сказать, что если не использовать полностью default, лучше на Gentoo жить с OpenRC. Как залогинюсь, закрою тему. Тут завершено.

Werenter, спасибо за полезный коммент.

а в чём, собственно, вопрос?

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

Gentoo. Игнорируются LLVM_TARGETS

Вот смотри

 ~ $ emerge -avtp llvm clang
[ebuild   R    ] sys-devel/clang-17.0.6:17::pg_overlay  USE="extra (pie) -debug -doc (-ieee-long-double) -static-analyzer -test -verify-sig -xml" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARC -ARM -AVR -BPF -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -SPIRV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa" PYTHON_SINGLE_TARGET="python3_12 -python3_11" 125,100 KiB
[ebuild   R    ]  sys-devel/llvm-17.0.6:17::pg_overlay  USE="libffi ncurses zstd -binutils-plugin -debug -debuginfod -doc -exegesis -libedit -test -verify-sig -xar -xml -z3" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARC -ARM -AVR -BPF -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -SPIRV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa" 2 KiB

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

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

firefox-esr с mozilla.org и из debian - разный fps

В Gentoo Wiki, особенно после статей на Reddit, вдруг стали писать пытливым умам, что FF содержит в себе много ржавчины и флаги ой как влияют на полученный результат.

Using GCC rather than Clang to compile Firefox makes Firefox have slower performance because Firefox has Rust code. Because both Rust and Clang uses LLVM, Clang is able to make better optimizations than GCC (This is subject to change with the GCC Rust).

Расскажи мне, о гуру, как сочитаются «USE flags» и «не надо собирать»?

В LLVM/Clang/Rust был баг, приводящий к невозможности пересборки, если до этого ты убрал флаг со своей платформой. Пацаны решили, что «танцуют все» и впендюрили по умолчанию весь набор «основных» по их ленивому мнению платформ, чтобы избавить себя от таких пунктов в багзилле. К чему это привело? К бесмыссленности пересборки без применения силы к бедному emerge.

Сейчас эти пакеты выглядят так:

[binary   R    ] sys-devel/clang-17.0.6-4:17::gentoo  USE="extra (pie) static-analyzer xml -debug -doc (-ieee-long-double) -test -verify-sig" LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai) (LoongArch) (MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) -ARC -CSKY -DirectX -M68k -SPIRV -Xtensa" PYTHON_SINGLE_TARGET="python3_11 -python3_10 -python3_12" 0 KiB
[binary   R    ]  sys-devel/llvm-17.0.6-4:17::gentoo  USE="binutils-plugin libffi ncurses xml -debug -debuginfod -doc -exegesis -libedit -test -verify-sig -xar -z3 -zstd" LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai) (LoongArch) (MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) -ARC -CSKY -DirectX -M68k -SPIRV -Xtensa" 0 KiB

Для непосвящённых - в скобочках прибито, пока ты ему не скажешь обратное (чего большинство не умееет и не знает), Ololo_Trololo, хак применил и теперь ему надо дублировать ключи в нескольких местах, о чём мы забываем и иногда долго не можем понять поведение emerge. На ЛОР всплывали темы, которые я привёл выше - Gentoo. Игнорируются LLVM_TARGETS

Сборка этого набора (а AMD требует включения флага в Mesa «LLVM»)заимает довольно ощутимый отрезок времени.

Ну и на закусь

Да, это талант: написать так много слов, а по сути ничего не сказать, да ещё и параллельно испортить воздух.

Пришло в тему и закинуло искромётный юмор:

libreoffice-bin, firefox-bin считается? Тогда я пробовал, полёт нормальный.

Да и насрать, но ты же продолжаешь гадить своим незнанием безграмотностью:

Но если бинарными будет значительная часть пакетов - зачем тогда Генту? Тогда это Debian, вы ошиблись дверью.

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

Что ты - неосилятор.

Это что же я «не осилил», мой собеседник? Подскажи, я с удовольствием стану больше разбираться в вопросе.

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

Спасибо, интересный опыт. Я дженту лет 10 не трогал. Помнится у меня там ещё у фаерфокса номер был 40-какой-то. Это где-то 2013-2014 год вроде.

Обзор дистрибутива Gentoo Linux в контексте компьютерной графики

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

Dimez, глянь, парень рекламой занимается. Бегает по некротемам и пихает свой канал. Осуждаю!

P.S. Он себя пиханул в «Решенную» тему, как-то так.

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

Она вполне оправдана. На бинхосте может не оказаться версии собранного бинарного пакета, если использовать старую версию списка пакетов.

И тогда возникнет ошибка при установке бинарного пакет и он должен собраться из ebuild`а.

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

Это некротема, всё разобрано до костей.

На дату не посмотрел. Просто стало интересно, Gentoo давно не щупал. Но когда-то использовал.

Попробуй бинарный опцион.