Размышления о Gentoo

+1

>главно достоинство Gentoo состоит вовсе не в оптимизации

Стереотипы трудно разрушить.

доли процента говоришь? при грамотной оптимизации некоторые приложения начинают работать от 1.5 до 3-х раз быстрее

ИМХО все эти ваши Генты, Убутны и вообще зоопарк дистров Линукса - это хорошо для кого-то, но например не для меня - я для себя давно собрал LFS и тащусь от него, чего и вам желаю с вашими дитрами. ИМХО в этом и есть истинное счастье - получить то что хочешь ты, а не то, что тебе кто-то навязывает.

>> ИМХО в этом и есть истинное счастье - получить то что хочешь ты, а не то, что тебе кто-то навязывает.

А ты Gentoo в глаза-то видел? Судя по твоему сообщению - нет.
Кстати, как в LFS обстоят дела с обновлением софта?

>ИМХО все эти ваши Генты, Убутны и вообще зоопарк дистров Линукса - это хорошо для кого-то, но например не для меня - я для себя давно собрал LFS и тащусь от него, чего и вам желаю с вашими дитрами. ИМХО в этом и есть истинное счастье - получить то что хочешь ты, а не то, что тебе кто-то навязывает.

а патчи ты откуда берёшь?

сам клепает, как лох. вместо того чтобы работать.

>доли процента говоришь? при грамотной оптимизации некоторые приложения начинают работать от 1.5 до 3-х раз быстрее

так, красноглазый, не позорь нас гентушников, где ты такие приложения видел ?

зы: единственное, что я помню на глаз - опенофис открывался быстрее раза в 2 и работал быстрее(даже на глаз), но это было гдето 1.0, о сейчас подтянулись...в других приложениях разници не замечал ни разу...

>при грамотной оптимизации

ззы: может я конечно неграмотный оптимизатор :)

> великолепнейшей системе USE-флагов

А как в Gentoo обстоит дела с зависимостями от USE-флагов другого порта?

> а в великолепнейшей системе USE-флагов

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

> А как в Gentoo обстоит дела с зависимостями от USE-флагов другого порта?

присоединяюсь к вопросу
а еще до меня доходили жуткие слухи, что при удалении пакета остается все-таки мусор, в /etc например

ЗЫ: и все-таки имхо компилять ВСЁ - это перебор, хотя для отдельных, важных приложений это удобно...

>так, красноглазый, не позорь нас гентушников, где ты такие приложения видел ?

Может быть, у него мышка начала быстрее по экрану ездить?

Mplayer.

А вообще, действительно, оптимизация ничего не даёт. Но я ценил этот дистр прежде всего за гибкость (USE), простоту (почти всё делается через emerge) и надёжность.

Вот только времени она отнимает - ужас!

Неужели у тебя за ночь OO не скомпилируется?

> Неужели у тебя за ночь OO не скомпилируется?

а если он мне нужен _сейчас_? я просто наберу apt-get install openoffice.org2-core и получу готовый к работе офис, причем качать придется намного меньше

в генте кстати тоже есть ебилд для openoffice-bin

USE-флаги для меня скорее минус чем плюс. Так как в других дистрибутивах мне нужно думать термином "пакет", а тут более низкоуровневый выбор, что не есть хорошо. В Gentoo надо выбрать для себя кучу флагов из сотни, а если что-то забудешь выбрать, а оно тебе понадобилось, компили заново. В других же дистрибутивах одна программа может разбиваться на несколько пакетов: amarok, amarok-helix-backend, amarok-libvisual, amarok-xine, amarok-helix, amarok-xmms, amarok-debuginfo, amarok-arts, amarok-gstreamer. Я себе ставлю скажем amarok, движок amarok-xine. Если я хочу поставить другой движок или библиотеку визуализации, я просто устанавливаю соответствующий пакет, а не пересобираю весь amaroK. Про оптимизацию: меня устраивает скорость и без неё. Прирост скорости на десять процентов я не замечу.

амарок жрёт столько процессора, что не волей думаешь: "а ты не подавишься, дитятко?". так что вопрос оптимизации потребления вычислительных ресурсов компьютера для него как никогда актуален ;). правда возможно не в SuSE, но всё равно. кстати, amarok-{xine,gstreamer,arts} виснут, глючат и крушат амарок. толькко amarok-helix работает более-менее стабильно + новые версии от гугуру или пакмана лучше не ставить - такого глюкалова я ещёне видел. почему-то нормально работает только офиц. сборка 1.3.1 =)

Ты просто не умеешь его готовить. Надо пользоваться либо 1.2 либо 1.3.4 и выше.

А вообще, как правило, если приложение жрет ресурсы, особенно процессор, то это ошибка в самом приложении, а не "недооптимизированность", так что пример с амароком, который просто коряво работал до недавнего времени с xine и gstreamer не имеет к оптимизации ровно никакого отношения. Кроме того, в Redhat, Suse или (k)ubuntu тоже не идиоты сидят, а я бы даже сказал, что наоборот, люди, вызывающие немного более доверия, чем анонимусы с ЛОР.

От себя же скажу, что раньше у меня была Fedora, теперь Kubuntu и я незамечаю ни RPMHell'a ни "файлопомойки", а оба дистрибутива мне кажутся очень логичными и удобными. Так что нравится собирать все по сусекам - собирай, только к другим не приставай.

USE-флаги, говорите? Тут как-то приводили ссылку на разговор суппорта в IRC, где ему задавали дурацкие вопросы, потом выяснялось что для корректной работы одной программы нужна другая, а у спрашивающего её нет... Суппорт говорил нечто вроде "Mysteriously, I guess you use Gentoo"

Подписываюсь под каждым словом.

>USE-флаги, говорите? Тут как-то приводили ссылку на разговор суппорта в IRC, где ему задавали дурацкие вопросы, потом выяснялось что для корректной работы одной программы нужна другая, а у спрашивающего её нет... Суппорт говорил нечто вроде "Mysteriously, I guess you use Gentoo"

Вот-вот. USE-флаги в портеже как ассемблер, неизменные пакеты в других дистрах - как скажем питон.

Согласен, хочу поставить Gentoo именно из-за USE.

> amarok-{xine,gstreamer,arts} виснут, глючат и крушат амарок. толькко amarok-helix работает более-менее стабильно

Н-да? Почему же на 4-х компьютерах, где стоит SuSE 10,только amarok-xine работает как часы, а helix заикается при любом действии (открытие меню, запуск программы и т д)?

> В других же дистрибутивах одна программа может разбиваться на несколько пакетов: amarok, amarok-helix-backend, amarok-libvisual, amarok-xine, amarok-helix, amarok-xmms, amarok-debuginfo, amarok-arts, amarok-gstreamer.

Такая вещь прокатывает только с теми приложениями, которые так спроектированны. Если же взять приложение типа mplayer, так там компилиться один исполняемый файл, который компонуется со множеством библиотек - это и кодеки, и видео/аудио выводы. Так, если сборщики решили, собрать его с arts,esound, svgalib (хотя ты ими не пользуешься), то тебе прийдётся их ставить в нагрузку, зато пакетёры могут решить, что mp3 не нужен. Где тут плюсы пакетной сборки?

LOOOL!!! Шутник! Ядро у меня компилируется 20 минут, kdelibs - 3-4 часа, ксорг - 2,5 часа. ОО, как я слышал даже на мощной машине компилоится несколько часов. Теперь прикинь сколько будет у меня, поскольку у меня celeron 600.

>Ядро у меня компилируется 20 минут, kdelibs - 3-4 часа, ксорг - 2,5
>часа. ОО, как я слышал даже на мощной машине компилоится несколько
>часов. Теперь прикинь сколько будет у меня, поскольку у меня
>celeron 600.
бинарные пакеты что ли собирать и выкладывать...?

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

Посмотри, как sdl в Debian выложен.
libsdl1.2debian-all - Simple DirectMedia Layer (with all available options)
libsdl1.2debian-alsa - Simple DirectMedia Layer (with X11 and ALSA options)
libsdl1.2debian-arts - Simple DirectMedia Layer (with X11 and aRts options)

И так далее. Если приложение ну никак не позволяет себя подобным образом собрать - его надо послать в биореактор или перепроектировать.

Вот SDL как раз и не позволяет себя так собрать, это просто разные сборки! А комбинаций там ого-го-го как много.

Всё ещё хочешь послать SDL в биореактор?

MPlayer отсутствует в большинстве дистрибутивов.

Блин, MPlayer для примера, второй пример уже сказали - SDL, его тоже в твоей сусе нет?

А ещё в большинстве дистрибутивов отсутствует mp3, и куча приложений собранно без его поддержки, тот же SDL_mixer например.

Повторяю ещё раз. Приложение, которое не позволяет собрать себя как указанная сборка sdl - должно отправиться в биореактор.

PS Для mplayer идеально подходит пакетная система Debian, с её recommends и suggests. Т.о. mplayer может предполагать наличие aRts, либо зависеть от одного из alsa|oss|aRts|esd (один из перечисленных должен быть обязательно). А ещё лучше, чтобы mplayer зависел от sound-system.

Кстати, в Debian его собираются включить... Впрочем, когда это будет сделано - неизвестно, ибо Мариллат ещё тот аццкий сотона.

+1

2Home user - с обновлением в LFS - все тривиально - сносится старое ставится новое. С подробным чтением чейнджлогом и оценкой адекватности обновления.

> Согласен, хочу поставить Gentoo именно из-за USE.

И играть по правилам мантайнера е-билда ??? Ню-ню...
Если тебе кажется, что тебе дали реальную свободу очччч рекомендую повтыкать форум генту там одна из вечных тем
- Я сказал USE="blah +blah -blah" emerge foo 
  А оно развалилось при     сборке или не фунциклирует
- А ну это из за того что ты не сказал USE="blah blah blah "
  когда собирал другую шнягу...

Маразм

Ну да. В KDE aRts оторвать, а к чему-нибудь ещё прицепить. И понеслась... А вообще-то идея неплохая, если бы система сама подобные вещи отслеживала... apt на уровне USE - круто! Кто возьмётся написать?

> apt на уровне USE - круто! Кто возьмётся написать?

Было бы супер! Вернулся бы на дебиан. Кстати есть еще идея о бинарных патчах или пакетах с вложенными объектниками и линковкой на целевой системе... Но к сож большинство авторов не станут перепахивать свои проекты.

Это скажем получается скрещивание Gentoo и Debian. А точнее - дебианизация Gentoo, два проекта сольются в один.

>Но к сож большинство авторов не станут перепахивать свои проекты.

Ну, на это есть package-maintainer. Уверен, многие разработчики понятия не имеют о Debian и о том, как в нём собирать пакеты. Тем не менее мы живы :)

> А точнее - дебианизация Gentoo

У генту моща не те что у дебиана. Так что скорее всего если и появится то как фича вроде apt-build + сервера с репозитариями объектников

Хорошо. Гентунизация дебиана :)

> Повторяю ещё раз. Приложение, которое не позволяет собрать себя как указанная сборка sdl - должно отправиться в биореактор.

Повторяю ещё раз, практически любое серьёзное приложение позволяет собрать себя так, но таких сочетаний в этих приложениях намного больше чем 3, даже в в том же SDL!

> PS Для mplayer идеально подходит пакетная система Debian, с её recommends и suggests. Т.о. mplayer может предполагать наличие aRts, либо зависеть от одного из alsa|oss|aRts|esd (один из перечисленных должен быть обязательно). А ещё лучше, чтобы mplayer зависел от sound-system.

Ну-ка, поподробнее, вот у меня стоят две sound-system: alsa, jackd и эмуляция oss.

apt-get mplayer тогда какую сборку mplayer мне поставит?

apt-build и deb-src это не совсем то, что emerge и USE... Вот я и говорю - скрестить их надо. Тогда открываются сумасшедшие возможности... Стоит в локалке сервак. Маленький такой, камней на 30. Так вот этот сервак занимается сборкой всего и вся по запросу пользователей. То есть у каждого получается свой собственный debian.

Поставят тебе то, что ты хочешь. Хочешь - mplayer-alsa, хочешь - mplayer-all. В последнем случае post-install скрипт спросит тебя, какую sound-system ты хочешь использовать. То есть я так себе это представляю. А вообще - читай тут мой отжиг про гентунизацию дебиана :)

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

> Поставят тебе то, что ты хочешь. Хочешь - mplayer-alsa, хочешь - mplayer-all. В последнем случае post-install скрипт спросит тебя, какую sound-system ты хочешь использовать.

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

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

Прекрасно тебя понимаю. Сам сейчас на дебе временно пока идет пересборка (ситуация получилась - пришлось "приложить" предыдущий билд).

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

Мне эта ситуация тоже жутко осто3.143дела поэтому сейчас на первых этапах попытаюсь по максимуму автоматизировать всякую мелочевку.

На то он и опенсорс - платить надо временем.

Отжиг конечно классный, но слишком тяжело это реализовать на собранных дистрибутивах, имхо в них надо улучшать систему сборки из сырцовых пакетов, чтоб человек мог (с помощью тех же USE флагов) собрать и поставить себе пакет без нежелательных зависимостей.

> Поставят тебе то, что ты хочешь. Хочешь - mplayer-alsa, хочешь - mplayer-all

$ cd ~/src/mplayer/main
$ echo "print 2**$(./configure --help | grep enable | wc -l)" | python  
79228162514264337593543950336

несколько сразу? А что, можно одновременно играть через разные ss?

А спрашивать будет, если сборщик пакета хорошо напишет post-install скрипты.