Время компиляции Gnome и KDE...

>paludis

как оно при использование? не слишком сырое? стоит ли ставить?

У меня за день собирается полностью с koffice, k3b и пр. на 1.8GHz

Совет: ругайся на плюсы и g++.

>У меня за день собирается полностью с koffice, k3b и пр. на 1.8GHz

1.8 бывает очень разный. от тупорылого афлона до горе-два-вдую

>как оно при использование? не слишком сырое? стоит ли ставить?

Если приключений не хочется (меня, вот, потянуло...) то не стОит пока.

Т.е. всё работает. Нравится бОльшая строгость, чем в emerge (много ошибок в портеже уже поисправлял... правда, все не логические, а синтаксические). Скорость... Местами реактивный, местами - такой же тормоз, как emerge, иногда - даже тормознее. В среднем - выигрыш есть, но не большой.

Хорошо то, что можно настройки компиляции индивидуально под пакет настроить. Плохо то - что через жопу. В егойном bashrc пишется switch, который в завсимости от текущего пакета прописывает иные CFLAGS.

Более корректный "revdep-rebuild" (у него скрипт на ruby).

Приятно, что сборка и установка в image идёт под юзером, под рутом - только инсталляция в систему.

Плохо - многие пакеты в сторонних оверлеях глючат. Все логи завалены:

... When performing cache regeneration action from command line:
... When generating VDB repository provides cache at '/var/db/pkg/.cache/provides':
... When loading VDBRepository entries from '/var/db/pkg':
... When loading VDBRepository entries for 'dev-lang' from '/var/db/pkg':
... When parsing package dep spec '=dev-lang/php-5.2.4_pre200708051230-r2' with parse mode 'permissive':
... When parsing version spec '5.2.4_pre200708051230-r2':
... Number part '200708051230' exceeds 8 digit limit

(пожмотились на 6 лишних байт :D)

Очень неудобные параметры командной строки. Запомнить их нереально, вручную набивать тоже. Только копипаст из мана каждый раз. Ну, или скрипты писать.

Нету даже обычного --resume --skipfirst. Хотя при каждой ошибке он выдаёт "строку" (размером, порой, до 20 строк :D) продолжения прерванной операции (т.е. со списком оставшихся пакетов и т.п.)

Хуже сделан вывод информации об обновлениях (в emerge цветовые выделения всех этих U/D/NS намного информативнее).

Часто не понимает сокращённую нотацию. Типа, apache вместо www-server/apache. Хотя так и не понял ещё, когда понимает, а когда - нет.

Каждое обновление пакета проводит как emerge с ключом "-D" aka "--deep", т.е. с обновлением зависимостей, даже если это не обязательно. соответственно - весьма рискованно. Приходится делать обязательный местный revdep-rebuild.

Плюс, правда - можно при обновлениях явно запретить downgrade пакетов. Мне это полезно :)

...

В общем, пока щупаю его на двух машинах, решаю, стоит оно того или нет.

тупорылый, с 64K_L2 :)

>Совет: ругайся на плюсы и g++.

Это и ежу понятно, но неинтересно :D

Потому в своё время я осилил собрать полный Гном под Слаку и LFS, что КДЕ компилился чёрти сколько, cc1plus жрал море памяти (стрёмно иной раз было пускать -j8, оно могло сожрать памяти почище чем сборка OpenOffice с тем же самым -j8) и конца сему было не видно. Либо нужно затевать богомерзкие игрища с переменными окружения, дабы не собирались ненужные утилитки и время сборки уменьшилось.

В гноме же сие автоматом - что не хочешь, то и не ставь, лишь бы зависимостей не было сверху.

>У меня за день собирается полностью с koffice, k3b и пр. на 1.8GHz

Да, забыл сказать, что у меня на Celeron-1700 оно собирается с nice +15, а в фоне висят активные rtorrent и mldonkey :)

второй день...
что-то уж больно долго :)

на производительность (вообще), в частности на скорость компиляции, много чего влияет.
погляди внимательно vmstat-ом где в твоей системе наиболее узкое место.

Если бы я ещё тут понять что-то реально мог :D

vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 8  1 448684 170336 101436 207236   35   21   167   134  144    2 57 15 17 11
 8  1 448684 166864 101436 207284    0    0    20     0  210  994 96  4  0  0
 8  1 448684 162532 101436 207528    0    0   212     0  212 1031 98  2  0  0
 9  0 448684 158192 101436 207584    0    0     0     0  197 1015 96  4  0  0
 8  1 448684 154164 101496 207764    0    0    84   552  201  993 96  4  0  0
 8  1 448684 142148 101496 208132    0    0   344     0  217  994 96  4  0  0
 8  1 448684 139048 101496 208308    0    0    16     0  202  986 96  4  0  0
 8  1 448684 136136 101496 208660    0    0    24     0  215 1067 96  4  0  0
 8  0 448684 132420 101496 209008    0    0   144     0  184  983 96  4  0  0
 9  1 448684 129384 101524 209400    0    0    68   952  249 1011 97  3  0  0

мдя
мазохизм какой-то

В каком он там месте? :) При работе на этом десктопе тормозов не заметно, разве что программы чуть дольше запускаются... ... а, нет. Сейчас переключился - притормаживает. Вся память сожрана на компиляцию ghc.

Чего-то косяки косяками попёрли. То qt не собирается, то с XML проблемы, теперь с mime. expat.so.0, будь он неладен... Попробовать ещё раз Гном, что ли?

> expat.so.0

Это боян. Кошерным является только expat.so.1.

атлон не тупорылый. тупорылое горе2дуба

/me тогда дождётся релиза в *, таки ~* некошерно а кеды аццки долго компилятся.. думаю даже слезть с них как ни будь (найти бы аналог по функционалу konqueror'у)

Фаерфокс, по функционалу делает конкверор в сотни раз по дефолту. Ну или продай велик и купи эппловский ноут.

Собираю по ночам. За ночь собирается kdebase, kdeadmin, kdenetwork, qt

Gnome на gentoo не хочу...

Писец, вот отдельным личностям делать нечего :)

> Собираю по ночам. За ночь собирается kdebase, kdeadmin, kdenetwork, qt

Полный гном за часов 5-6 соберётся, включая firefox/openoffice, такой как у тебя расклад я видел на p3-700 :)

> Gnome на gentoo не хочу...

Ну и зря.

Кстати, эти отщепенцы еретики-мейнтейнеры гентушные только неделю назад додумались сменить libexpat на версию 2.0.х, тогда как все грамотные люди сделали это столетие назад. А тривиальный воркэраунд вида ln -s libexpat.so.1 libexpat.so.0 - таки никто и нигде не додумался сделать...

Чем люди думают...

>Ну и зря.

У мну ubuntu с gnome на другом разделе имееться, так что на gentoo будет KDE однозначно...

P.S.И ниипет :)

>Совет: ругайся на плюсы и g++.

++1 Стас прав..

> Полный гном за часов 5-6 соберётся, включая firefox/openoffice, такой как у тебя расклад я видел на p3-700 :)

Щаз. Опенофис у тебя суток двое собираться будет на такой машине.

Firefox у меня на PIIIM-933 собирался почти 2 часа.

> Щаз. Опенофис у тебя суток двое собираться будет на такой машине.

Гарантированно менее 16 часов с херовой тучей опций и т.п., проверено Занусси и лично мной.

> Firefox у меня на PIIIM-933 собирался почти 2 часа.

Дык от кармы всё зависит, кому Патрег и Бекманс благоволят - те +100% бонус получают к скорости ;)

Хм, когда-то я собирал КДЕ 3.3.2 под Мандрякой 10.1 :) На П4 2.8Ггц весьма быстро собралось, не больше часа(плохо помнится) :)

> Щаз. Опенофис у тебя суток двое собираться будет на такой машине.

Зачем так извращатся?

Щас кто-нибудь с 486 вылезет =)

Патрик? :)

> vmstat 1 10

вот и посмотри что у тебя происходит...
есть b>0, значит процессы ждут воода/вывода (видисо с винта).

конфигурацию машинки, и параметры компиляции не знаю, поэтому дальше сложно рассуждать.

> А тривиальный воркэраунд вида ln -s libexpat.so.1 libexpat.so.0 - таки никто и нигде не додумался сделать...

Покопайся на forums.gentoo.org -- там подробно объясняют почему этого не стали делать. Кратко: "косяки ловить сложнее" и "revdep-rebuild запутается".

>expat.so.0, будь он неладен...

Да... Я как-то незаметно это пережил (благо, две машины, на одной работаешь, другая чинится :D) но кому-то это дело нервов попортило...

Вообще, ИМХО, золотой век Gentoo был где-то в 2004-м году. Народ тогда очень ответственно к вопросам надёжности сборки подходил.

>конфигурацию машинки,

LVM из трёх винтов, системные разделы на ReiserFS.

> и параметры компиляции не знаю

CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe -s"
LDFLAGS="-Wl,-O1"

>Так вот, Gnome обновился почти моментом (т.е. я не помню уже, когда обновился последний его пакет) и... второй день (машинка - Celeron-1700, а distcc под paludis ещё не настраивал) собирается KDE... :D

Бредятина какая-то... У меня (AthlonXP 1800+) самое тормозное - это Openoffice.org, собирается 8-9 часов. А что кеды, что гном - ощутимо меньше. Правда, я не ставил ВЕСЬ кде, а выбирал что ставить, а что нет (например, koffice у меня нет).

> CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe -s"

О3 заменить на О2, а "-fomit-frame-pointer -pipe" снести к чертям, ибо с++-ный код пухнет и тормозится с этим флагом. Разницы в скорости почти не будет, а вот пасять начнёт отъедаться пожиже.

> Покопайся на forums.gentoo.org -- там подробно объясняют почему этого не стали делать. Кратко: "косяки ловить сложнее" и "revdep-rebuild запутается".

Да ну их всех в топку, это ещё проще лечится - созданием симлинков в директориях пользователей и установкой кошерного LD_LIBRARY_PATH на время revdep'а.

Потому как, если мне не изменяет память, смена версии либки не повлекла смены API, и в принципе можно совсем просто поступить, тривиально пропатчив сорцы на предмет ".so.0" заместо ".so.1", устранив проблему в зародыше. А так, пля, мне вот счас опенфосис пришлось пересобирать по милости гентушных раздолбаев, что 2 года ниасиливали воткнуть свежий expat.

>О3 заменить на О2, а "-fomit-frame-pointer -pipe" снести к чертям, ибо с++-ный код пухнет и тормозится с этим флагом. Разницы в скорости почти не будет, а вот пасять начнёт отъедаться пожиже.

Да мне ж не руками мешки ворочать. Лучше пусть один раз пару дней потормозит при обновлении (тем более, что не на рабочей машине, а на домашнем серверке), зато потом будет на пару процентов шустрее на многие месяцы :D

>А так, пля, мне вот счас опенфосис пришлось пересобирать

А чем не кошерна infra-сборка? :) Я какое-то время OOo сам собирал, а потом забил.

А с О2 оно не дни будет "тормозить", а вовсе даже "часы", а то и поменьше. Там жеж при О3 расход памяти при компиляции колоссальный и процессорное время на сложных сорцах уходит как кагорчик в мою бездонную глотку.

> А чем не кошерна infra-сборка? :) Я какое-то время OOo сам собирал, а потом забил.

А она есть версии 2.2.1 и под native-amd64? ИМХО эти лузеры до сих пор полагают, что x86_32 - всеобщее светлое будущее, а на рабочей станции не может стоять более 1-2 Гб физической памяти.

>А с О2 оно не дни будет "тормозить", а вовсе даже "часы", а то и поменьше.

У меня сервер под O2 сидит. Разница во времени не принципиальная :) Да и на amd64 какое-то время под O2 сидел, пока глючило что-то с O3.

Памяти - не жалко, как раз. Я ж за той машиной не сижу, а оперативки - гиг.

...

А вот с paludis'а, видимо, сползать буду. Делаю местный revdep-rebuild, выясняется, что надо gnome-games пересобрать (насколько понимаю, это как раз ещё последслвия libexpat.so.0), запускаю пересборку - а он мне обновляет пять пакетов, включая udev. Т.е. та же хрень, что --deep у emerge. Закончишь такую сборку - обязательно придётся опять revdep-rebuild делать... И так без конца :D Система, конечно, вся свежая будет, но --deep - это для тех, кому процесс обновления сам по себе важен и интересен, как самоцель :D

Так что, наверное, обновлю сейчас систему, да и вернусь назад на emerge.

>и под native-amd64? ИМХО эти лузеры до сих пор полагают, что x86_32 - всеобщее светлое будущее

А, ну если только так... А я как слез весной с amd64, так и доволен как слон :D

> надо gnome-games пересобрать (насколько понимаю, это как раз ещё последслвия libexpat.so.0)

И libcurl тоже. Если же тебе это только предстоит - то сочувствую, и рекомендую пользовать ключик линкера "-Wl,--as-needed", капитально число пересобираемых пакетов уменьшает ;)

> но --deep - это для тех, кому процесс обновления сам по себе важен и интересен, как самоцель :D

Дык а как иначе, ежели хрень какая потребует обновление неявной зависимости (типа XML-parser, столь нежно любимый гнумом) - без этого долго придётся шариться и накладывать --oneshot'ы.

>И libcurl тоже.

Судя по eix 5 дней назад пересобрался.

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

А зачем? Если имеющиеся версии удовлетворяют обновляющийся пакет, зачем их-то обновлять?

> без этого долго придётся шариться и накладывать --oneshot'ы.

Кстати, никогда не понимал, нафига нужен --oneshot? :) Никогда им не пользовался. Если пересобираю пакеты, то всегда "честно".

> А, ну если только так... А я как слез весной с amd64, так и доволен как слон :D

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

> А зачем? Если имеющиеся версии удовлетворяют обновляющийся пакет, зачем их-то обновлять?

А если не удовлетворяют?

> Кстати, никогда не понимал, нафига нужен --oneshot? :) Никогда им не пользовался. Если пересобираю пакеты, то всегда "честно".

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

> CFLAGS="-O3 -march=pentium4 -fomit-frame-pointer -pipe -s"

Ооо!

Мне вас искренне жаль.

"-s" смущает? ;)

Смущает -O3 -fomit-frame-pointer -march=pentium4 - в порядке убывания ... - даже не знаю как тут можно вежливо выразиться. Лучше помолчу.