Gentoo vs Debian 13 in 2025?

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

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

даже где-то backup был
и да, ryzen 7700X, 32Gb, nvme

Ставь Gentoo, как надоест переметнешся на Debian

на работе debian12, бесит своими делениями библиотек.

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

С gentoo надо быть «на острие» и обновлять регулярно, иначе на месяц забьешь и потом будешь ночь сидеть и разбирать ошибки.
Но если разобраться с use флагами, то да система на gentoo получается пошустрее и меньше странных багов из-за ненайденных recommended библиотек.

Если «хочешь новых ощущений» - NixOS

Debian.

В требованиях нет ничего что могла бы только Gentoo.

Для тех, кто думает перейти на Gentoo

Gentoo может в свежие компиляторы, Debian - или ждать или собирать (Go, C# etc).

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

нововведения очень люблю трогать руками(go, rust)

ты же за CRUX топил, забыл?

Что лучше

конечно дебиан - собирать мир это геморой

нет, не забыл, сейчас объёмный мир portage даёт в моём случае лень.

зависит от того, что ты больше любишь: е-ться с компом или работать на нём… :)

оба варианта )))

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

Зависит от сложности системы. Компактную систему с малым количеством юз-флагов можно обновлять раз в несколько лет, если при этом знаешь, что делаешь. К тому же всегда есть архивы срезов portage.
А вот какой-нибудь гном или плазма - могут развалиться запросто.
Ещё может создавать проблемы qt - недавно пересобирал qt на старой системе и обнаружил что гентушные патчи, нужные для сборки 5.15.10 уже не найти - мейнтейнер-негодяй снёс их со своего сервера и на зеркалах не сохранились. Пришлось побирать 5.15.11 из ~amd64, на него патчи пока что были.
Если обновлять систему через несколько лет - проше снести qt и всё, что от него зависит - так меньше пересобирать.
Для себя уже проработал механизм обновления системы через несколько лет:
обновляем шагами срезы по 2 года. Можно маскировать gcc, llvm/clang и python (для этого у меня специальный конфиг с масками dont-update-compilers)
Потом когда добираемся до актуальной версии, либо когда уже позарез нужна новая версия компилятора - маска убирается и он обновляется до версии посвежее.
Крупные пкеты вроде браузеров, qt в принципе можно посносить заранее, чтобы не цеплять все промежуточные их версии. Всё равно потом накатывать с нуля и пересобирать новыми компиляторами.
В целом по сборке крупное обновление почти равносильно сборке из stage3, за исключением разве что разрешения циклических зависимостей с ребилдами (как cmake-libarchive-lz4), основной плюс - не надо переносить конфиги и настраивать всё с нуля
Так же я всегда явно выставляю PYTHON_TARGETS и PYTHON_SINGLE_TARGET, а всё что выше - пихаю под маску. Потом, когда требуется новый питон - уже разом всё обновляю, обновляя эти флаги и маску. Это куда лучше, чем иметь 3-4 версии питхона с разными наборами библиотек

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

мне Proxmox на работе хватает, а тут домашнее…

то да система на gentoo получается пошустрее

В чем пошустрее? Система получается такая же как и в обычном бинарном дистрибутиве. Кто вам прививает этот стереотип?

)) отклик явно шустрее.

Аналогичный. Другое дело если ты себе навернул что он шустрее.

благодаря уменьшениям зависимостей при сборке и +10% под железо tune compilator

первое рулит, компилятор я лично видел вывоз прироста в некоторых программах (когда-то долго игрался после перехода BSD на Clang линкерами (mold, gold etc) и lto)

Тоесть уменьшая зависимости у тебя система работает быстрее? Определение флагов процессора не дадут тебе ускорения системы.

даёт, но, например, в ffmpeg, в xorg, nodejs, mesa (не забываем spirv-tools) и wine.

А, забыл и шифрование и всё, что с ним работает. Ну и недавно мода пошла на утилиты с avx512…

go, rust

А что, их кто-то ставит пакетным менеджером? Но зачем?

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

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

в большинстве случаев

media-video/ffmpeg
media-libs/x264
media-libs/x265
dev-python/numpy
media-libs/opencv

Одни всё в хомяк

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

Есть примеры исключений?

закинул grep навскидку выше

просто берёшь любой процесс и смотришь /proc/${pid}/maps
В арче там адъ кромешный, полный нерелевантной фигни. Например какой-нибудь nouveau на системах, где новидией и не пахнет или boost в gdb.
Конечно же всё это увеличивает время запуска и memory footprint, засоряет адресное пространство. Переключение контекстов может стать медленнее, ядру больше работы по обслуживанию всего этого бордака. А главное - каждая лишняя зависимость может являться дополнительной точкой отказа. В mesa решили объединить все драйвера в один gallium бинарник, притом что боольшая часть драйверов не требует даже llvm. Но в бинарном дистре он обязательно будет прилинкован. Фактически сейчас можно даже на amd выкинуть llvm, а для swrast оставить только softpipe (жутко медленный, правда), но официально вроде как отключение не предусмотрено пока. так что такое только ручками пока что

Твои примеры относятся к случаям, когда во всех нормальных дистрибутивах (и даже Debian) векторные инструкции включены при сборке пакета.

возможно плацебо
я на gentoo сидел во времена kde4

дебиан для такого кучу лишних зависимостей притащит

Я как бывший гентушник помню, что у меня было две версии llvm, go, nodejs и еще кучка всяких компиляторов/тулзов для сборки программ. Хорошо хоть раст есть бинарный, а то все это добро собиралось бы еще дольше.

С llvm вообще цирк. У него довольно длительная сборка, ведь кроме x86_64 включены все остальные архитектуры, потому что:

Unfortunately, disabling targets tend to break reverse dependencies (e.g. Rust) and we are yet to find a clean way of resolving that. Compared to the damage potential, the increase of build time is a minor problem

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

позапариться с конфигом портажа?

Да ничего там не надо париться, копипастишь из хендбука основные параметры и выбираешь десктопный профиль в котором уже все нужное включено, например desktop/plasma/systemd. Все остальное можно настроить, если появится желание.

Gentoo с тильдой ставь (тестовую ветку). Ведро и критичные программы можешь тянуть из стабильной.

С llvm вообще цирк. У него довольно длительная сборка, ведь кроме x86_64 включены все остальные архитектуры, потому что:

отлючить можно всё ненужное и будет работать.

[ebuild   R    ] llvm-core/clang-20.1.8:20/20.1::gentoo  USE="extra (pie) -debug -doc (-ieee-long-double) -static-analyzer -test -verify-sig -xml" LLVM_TARGETS="AMDGPU BPF (SPIRV) (X86) -AArch64 -ARC -ARM -AVR -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa" PYTHON_SINGLE_TARGET="python3_13 -python3_11 -python3_12 -python3_14" 144082 KiB
[ebuild   R    ]  llvm-core/llvm-20.1.8:20/20.1::gentoo  USE="libffi zstd -binutils-plugin -debug (-debuginfod) -doc -exegesis -libedit -test -verify-sig -xml -z3" LLVM_TARGETS="AMDGPU BPF (SPIRV) (X86) -AArch64 -ARC -ARM -AVR -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa" 0 KiB

Поставить Calculate linux для быстроты установки, а из него уже лепить то, что нужно.

две версии llvm

Обычно чтобы такого не было, маскируют одну. Если конечно нет необходимости в двух

ведь кроме x86_64 включены все остальные архитектуры

Всегда отключаю их принудительно. То, что написано в причине маске там про rust - звизжёж, что rust-bin, что сам rust работают. Мейнтейнеру, это сделавшему лучше бы что-то полегче мейнтейнить. Возможно там был временный баг, который быстро починили (когда-то я натыкался на ошибки линковки в rust и это вероятно оно и было, но в 15й+ версии всё ок), а теперь страдают все пользователи, не убравшие за ним г-но. А вообще такие баги должны правиться не в llvm, а в самом rust. Например, принудительно требовать эти use-флаги в ебилде rust'а или бандлить свой llvm, как тот же rustup делает.
Сейчас паразитное требование мне напоминает вот это вот:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36968
Давайте зафорсим zink всем пользователям невидии из-за того, что дистры его не собирают (даже тем, у кого условный gt240 и zink никогда там не заработает)

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

У меня сейчас llvm и clang в рабочей системе только потому что я сам их поставил (нужен альтернативный компилятор), в зависимостях других пакетов их нет, в домашней оно притащилось mesa, хотя де-факто оно там уже не нужно, можно обойтись одним лишь aco, а для swrast есть медленный softpipe. Но где-то я вынужден был править ебилды т.к они притаскивали паразитные зависимости. То же самое кстати в qtcreator, который тащит половину kde в дефолтном ебилде (если ещё не пофиксили конечно)
Конечно хорошо бы это всё прорепортить, но мне лень. Обычно собрал систему и работает, раз в полгода-год дёргаю обнову, обновив патчи ебилдов при необходимости - а так ещё писать, потом проверять какие-то изменения, снова кучу всего пересобирая.

Для меня основной плюс gentoo что можно иметь систему без тильды, но тащить туда софт (и при необходимости libc) с тильды. В противовес арчу, где возможность ставить свежий софт даётся ценой сырой бетки во всей системе

У меня наоборот: система с тильдой, но кое-что без тильды ставлю.

ну тоже имеет смысл, держать стабильными отдельные пакеты.
Я ещё ядро обычно собираю со среза гита, а потом изредка докидываю поверх патчами багфиксы. Это обычно лучше работает чем релизы и lts, т.к оно ближе к тому, чем реально пользукются разработчиками. К сожалению от багов это не спасает и приходится уже потом закрывать задним числом

Как относишься к тезису «Manjaro - система для разработчика»?

А что мешает разработчикам писать под другие системы?

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

Например какой-нибудь nouveau на системах, где новидией и не пахнет

вранье же. даже пакет linux-firmware разбили на десятки других чтобы сэкономить 20-30 мегабайт на установке ненужного