Я сижу на amd64. Тоже поставил довольно недавно. Использовать или нет стабильную ветку - дело ваше. Ядро я бы посоветовал в любом случае ставить из стейбла, так как с последним (2.6.33) тоже были конфликты с проприетарными драйверами nvidia. По поводу гнома ничего не могу сказать, openbox наше всё. :) Попробуйте собрать moc со всеми флагами, которые доступны (equery uses moc - там всё описано). С jpeg'ом тоже не хотело работать, уже не помню как решил проблему, но imlib там таки мелькал, да...

http://www.gentoo.ru/node/13758

советуют пересобрать gtk+ c jpeg

Был там недавно. Пробовал, не помогло. Видимо, нужно копать в другую сторону.

http://bugs.gentoo.org/show_bug.cgi?id=275101

re-emerge gnome-panel
Try rebuilding gnome-menus

в случае с mp3 и jpeg должно помогать:
emerge -av --update --deep --newuse world

идея ACCEPT_KEYWORDS=«~amd64» для слабых духом и не осиливших /etc/portage/package.*

последнее ядро 2.6.33 дружит с nvidia-drivers 190.x и 195.x

>Во-первых moc не хочет видеть mp3 файлы и читать их
echo «media-sound/moc mad» >> /etc/portage/package.use

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

включи юз-флаг jpeg глобально и сделать emerge -uDN world

И вообще советую поставить desktop профиль, там уже эти флаги включены к примеру. (eselect profile)

Спасибо большое за совет с профилем. Помогло. Можно ещё ткнуть пальцем где выставлены use-флаги в этом профиле. Я так понимаю, не в /etc/make.conf?

Ох уж эти джентушники. Толку-то от оптимизации не больше ~5%, а сколько тратится времени на компиляцию??? Я вот на одном внутреннем сервачке, где стоит джента, устанавливал апач - часа полтора можно было «курить в сторонке». Другое дело - «кошерные» архитектуры, типа МИПСа: для них еще бинарные сборки не очень активно делают.

>оптимизации не больше ~5%
за вами выехали!

еще с целью допила советую baselayout2 воткнуть. очень уж оно с первой веткой задумчиво грузится

за вами выехали!

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

а кто сказал что смысл в оптимизации?

>практически не видно

кодирование музыки/видео очень даже
p.s. use флаги и выбрасывание ненужных сущностей при компиляции же!

Кто сказал, что дело в оптимизации?

Дело в удобном пакетом менеджере и в USE-флагах (сам себе мантейнер, хочешь - выкинь hal, networkmanager и pulseaudio, привет, убунта). Плюс плавное обновление и стабильность (привет, арч)

устанавливал апач - часа полтора можно было «курить в сторонке»

$ time sudo emerge apache -av

[ebuild   R   ] www-servers/apache-2.2.14-r1  USE="ssl -debug -doc -ldap (-selinux) -static -suexec -threads" APACHE2_MODULES="actions alias asis auth_basic auth_digest authn_alias authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cern_meta charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dumpio env expires ext_filter file_cache filter headers ident imagemap include info log_config log_forensic logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http rewrite setenvif speling status substitute unique_id userdir usertrack version vhost_alias" APACHE2_MPMS="-event -itk -peruser -prefork -worker" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

....

real    5m15.749s
user    2m48.731s
sys     0m24.514s

И это на стареньком селероне!

Не хочешь постоянно компилить? Обновляйся раз в месяц.

Еще вопросы?

>Если бы эта оптимизация при компиляции позволяла хотя бы в 2-3 раза
было и такое - один и тот же набор запущенного софта в генте занимал в 2 раза меньше памяти, чем в мандре!!!
а вообще - не знаешь (На примере своих знакомых гентушников говорю) то не неси ерунду!

>привет, убунта
это точно, когда в 9.10 из гнома выкинули нормальный микшер в пользу пульсаудио, это стало последней каплей

А что мне выбрать?

Арч или генту? Что лучше, интересует поддержка видеокарт от какт^Wати?

хочешь - выкинь hal, networkmanager и pulseaudio

О, еще один плюс дженты.

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

Смысл прежде всего в том что ТЫ САМ выбираешь: какой именно софт, с какими параметрами и с какими оптимизациями собирать…

Ускорение в 1-2 порядка реально если собирать к примеру с -msse4.1 а сравнивать с дефолтным дистром под стандартные х86 ;)

Арч или генту? Что лучше, интересует поддержка видеокарт от какт^Wати?

Выбери nvidi-ну ты понял

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

у автора темы есть еще какие-либо неотвеченные вопросы?

1) в USE добавить mp3 lame jpeg

3) конфликты надо подробнее расписывать, а не заставлять телепатов угадывать)

>интересует поддержка видеокарт от какт^Wати?
Это от дистрибутива не зависит как бы...

я выбрал ати.

я выбрал ати.

А при чем тут то что ты выбрал? С ати одинаково плохо во всех дистрах. Хотя да опять же в генте возможностей «подшаманить» и таки добится более менее нормальной работы больше… В то время как с нвидиа проблем нет никаких!

Можно ещё ткнуть пальцем где выставлены use-флаги в этом профиле.

Юз-флаги берутся из многих мест, в т.ч. сами профили состоят из нескольких частей. Смотрим:

ls /usr/portage/profiles/default/linux/x86/10.0/desktop/
eapi  parent

cat /usr/portage/profiles/default/linux/x86/10.0/desktop/parent 
..
../../../../../targets/desktop

cat /usr/portage/profiles/targets/desktop/{make.defaults,package.use}

И так далее по цепочке...

То, какие флаги получатся в итоге можно посмотреть с помощью emerge --info | grep USE
Порядок наследования описан в man make.conf (USE_ORDER)

А ещё есть удобная тузла flagedit, чтобы всё время руками не лазить в конфиги.

Хочешь десктоп - ставь ~amd64. Стабильная ветка слишком медленно обновляеться. Проблемы бывают редко и решаються они быстро.

У Gentoo одна из самых больших вики. Например nvidia - http://en.gentoo-wiki.com/wiki/Nvidia.

Calculating dependencies... done!
[ebuild N ] dev-perl/Text-Iconv-1.7 11 kB
[ebuild N ] dev-perl/HTML-Tagset-3.20 8 kB
[ebuild N ] dev-perl/DelimMatch-1.06 9 kB
[ebuild N ] dev-perl/XML-XPath-1.13 39 kB
[ebuild N ] dev-perl/Tie-IxHash-1.21-r1 7 kB
[ebuild N ] dev-perl/XML-Filter-BufferText-1.01 3 kB
[ebuild N ] dev-perl/libxml-perl-0.08 63 kB
[ebuild N ] dev-perl/HTML-Parser-3.64 USE="-test" 87 kB
[ebuild N ] dev-perl/XML-Handler-YAWriter-0.23-r1 26 kB
[ebuild N ] dev-perl/XML-SAX-Writer-0.52 25 kB
[ebuild N ] dev-perl/HTML-Tree-3.23 119 kB
[ebuild N ] dev-perl/Crypt-SSLeay-0.57 121 kB
[ebuild N ] dev-perl/libwww-perl-5.834-r1 USE=«ssl» 262 kB
[ebuild N ] dev-perl/XML-Twig-3.32 USE=«nls» 338 kB
[ebuild N ] dev-util/libconf-0.42.10-r2 USE=«python -ruby» 199 kB
[ebuild N ] app-portage/flagedit-0.0.8 6 kB


да ну ее )

Всё, с вопросами разобрался. Огромное спасибо за раскрытие глаз на профили. =) Пока всё из стабильной ветки, но, версии пакетов древнющие, завтра же обновлюсь с ~amd64. Всем спасибо.

> завтра же обновлюсь с ~amd64. Всем спасибо.
Заметил что многие гентушники (в т.ч. и я) проходят эти стадии:
~arch (не дистрибутив) -> надоело работать напильником -> arch + размаскировка отдельных пакетов.

а я начинал с ~arch года 3-4 назад. Так с тех пор на десктопе и использую ~arch. На серверных машинах, понятное дело, только стабильная ветка.

Я бы не советовал лезть в нестабильную ветку, лучше уж тянуть оттуда только необходимые пакеты. Хотя, о стабильности стабильной ветки я бы поспорил, лично мне, когда я собирал что-то Portage отказался отображать зависимости для какого-то пакета, как оказалось - баг. Пришлось тянуть его из ~arch. В любом случае мигрировать arch->~arch ты сможешь всегда, а наоборот - нет.

//moc, ЕМНИП, использует libmad, а не lame

> а наоборот - нет.
Ну почему же, я мигрировал успешно :)
Есть свои заморочки (например с glibc), но можно.

Естественно мигрировать с arch на ~arch проще.

например с glibc

Во~от. И не только с ним(ней?).

Может быть и проще, но не всегда просто. У меня тоже amd64. emerge -auvDN world с выставленным ~amd64 просто положил меня на лопатки. Во-первых компиляция _очень_ многих пакетов вылетала с ошибками, гуглить которые я просто устал, а во-вторых я мельком успел заметить, как во времея персборки проскочила какая-то информация про fstab, но я не обратил внимания(что-то там про формат в fstab'e) В итоге, хоть система и грузилась чудесным образом, fdisk -l показывал _только_ флешку (:)) и ничего, кроме / смонтировано не было.

news? etc-update?

какие страсти все описывают.. слетевшие fstab-ы, не подымающиеся glibc-ы и прочие ужасы)))
все это ерунда - все работает, ничего не слетает, а если и слетает - легко подымается обратно. но все это при одном НО - если человек понимает что он делает и знает куда в случае чего копать, а иначе действительно будет тихий ужас (для вчерашнего убунтушника).
на стабильной ветке -upvDN обычно не приводит к каким-либо серьезным последствиям (конфликтам, глюкам), а вот на ~arch это на много более вероятно, хотя бы потому, что никто не тестит долго и в итоге мы часто имеем обновление с последующей маскировкой ебилда (после первого же багреппорта). поэтому на ~arch бездумное, красноглазое обновление (по крону каждые 3 часа) может действительно боков напороть...
короче нужно понимать что ты хочешь и какие это за собой повлечет (может быть) последствия. хочешь гном из ~arch - размаскируй гном и сопутствующие либы и будь готов к тому, что после очередного апдейта у тебя что-нить да слетит или просто потребует пересборки (а это время и умственная деятельность). полностью перелез на ~arch - будь готов в квадрате))) но это я не пугаю и ниче такого, я например вообще 1-2 серьезных (скажем не решаемых за 30 мин) случая таких помню за почти 6 лет, так что....

про какое-то ускорение (говорилось про оптимизацию, но «оптимизация» там явно много больше 5% будет, так что назовем это ускорением) вообще читать смешно. люди говорящие о 5% ускорении генты вообще не понимают ничего в генте, а иначе они бы не говорили о ускорении. тут уже выше заметили что дело вовсе не в ускорении...

было и такое - один и тот же набор запущенного софта в генте занимал в 2 раза меньше памяти, чем в мандре!!!

у меня есть vs с гигом диска и 128 RAM, так там вполне себе живут друпал и пхпбб, при чем на базу ушло метров 400 минимум))) да, компиляция естественно не там...

простите за оффтопик,но может кто-нибудь из пользователей ~x86 попробовать пересобрать mail-client/mailx

если не соберется - отпишите в багзиллу, если есть регистрация

gcc -D_BSD_SOURCE -DDEBIAN -g -Wall -IEXT -march=pentium4 -mtune=core2 -Wa,-mtune=core2 -msse2 -mmmx -fomit-frame-pointer -O2 -pipe -c fio.c -o fio.o
In file included from rcv.h:43,
                 from fio.c:41:
def.h:112:1: warning: "offsetof" redefined
In file included from /usr/include/unistd.h:227,
                 from def.h:56,
                 from rcv.h:43,
                 from fio.c:41:
/usr/gcc-4.4/bin/../lib/gcc/i586-sylvia-linux/4.4.4/include/stddef.h:411:1: warning: this is the location of the previous definition
fio.c:150:35: error: macro "offsetof" requires 2 arguments, but only 1 given
fio.c: In function 'setptr':
fio.c:150: error: 'offsetof' undeclared (first use in this function)
fio.c:150: error: (Each undeclared identifier is reported only once
fio.c:150: error: for each function it appears in.)
make: *** [fio.o] Error 1
 * ERROR: mail-client/mailx-8.1.2.20050715-r1 failed:
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  54:  Called src_compile
 *   environment, line 2598:  Called die
 * The specific snippet of code:
 *       make EXTRAFLAGS="${CFLAGS}" || die

там offsetoff добавили в глибц, а у них свой не знал как обозвать, зато работает -

diff -urN mailx-8.1.2-0.20050715cvs.orig/def.h mailx-8.1.2-0.20050715cvs.orig.patched/def.h
--- mailx-8.1.2-0.20050715cvs.orig/def.h        2003-10-14 15:50:20.000000000 +0300
+++ mailx-8.1.2-0.20050715cvs.orig.patched/def.h        2010-03-25 02:49:35.000000000 +0200
@@ -97,7 +97,7 @@
  * Given a file address, determine the block number it represents.
  */
 #define blockof(off)                   ((int) ((off) / 4096))
-#define offsetof(off)                  ((int) ((off) % 4096))
+#define _offsetof(off)                 ((int) ((off) % 4096))
 #define positionof(block, offset)      ((off_t)(block) * 4096 + (offset))

 /*
diff -urN mailx-8.1.2-0.20050715cvs.orig/edit.c mailx-8.1.2-0.20050715cvs.orig.patched/edit.c
--- mailx-8.1.2-0.20050715cvs.orig/edit.c       2004-05-24 19:34:32.000000000 +0300
+++ mailx-8.1.2-0.20050715cvs.orig.patched/edit.c       2010-03-25 02:50:06.000000000 +0200
@@ -111,7 +111,7 @@
                        (void)fseek(otf, 0L, 2);
                        size = ftell(otf);
                        mp->m_block = blockof(size);
-                       mp->m_offset = offsetof(size);
+                       mp->m_offset = _offsetof(size);
                        mp->m_size = fsize(fp);
                        mp->m_lines = 0;
                        mp->m_flag |= MODIFY;
diff -urN mailx-8.1.2-0.20050715cvs.orig/fio.c mailx-8.1.2-0.20050715cvs.orig.patched/fio.c
--- mailx-8.1.2-0.20050715cvs.orig/fio.c        2004-05-24 19:34:32.000000000 +0300
+++ mailx-8.1.2-0.20050715cvs.orig.patched/fio.c        2010-03-25 02:49:52.000000000 +0200
@@ -139,7 +139,7 @@
                        this.m_size = 0;
                        this.m_lines = 0;
                        this.m_block = blockof(offset);
-                       this.m_offset = offsetof(offset);
+                       this.m_offset = _offsetof(offset);
                        inhead = 1;
                } else if (linebuf[0] == 0) {
                        inhead = 0;

я написала не потому что мне нужно собрать, а потому что в багзиллу бы кто им кинул, а то уже месяц такое «счастье» и кажется никому нет дела,
mailx достаточно старый, но у меня что-то его тянет, /bin/mail команда востребованная в системе вообщем-то

ps:
http://bugs.gentoo.org/show_bug.cgi?id=305251
вот бага, но хорошо бы пофорсить ее к тому чтобы пропатчили в дереве, а не висело как NEW

понятно. ну и че куда писать-то, в смысле кого ткнуть-то? я не представляю, там вроде и так все как нужно оформлено...
просто ругаться что ли?

это не ко мне пока ) я пока не отписывалась в гентушной багзилле ни с чем

> Может быть и проще, но не всегда просто. У меня тоже amd64. emerge -auvDN world с выставленным ~amd64 просто положил меня на лопатки.

Ну это проблемы не апгрейда как такового, а проблемы самого ~amd64.

> не подымающиеся glibc-ы
Просто даунгрейд glibc не поддерживается официально.
Либо ручками, либо сидеть и ждать стабилизации текущей или выше версии.

Вот я думаю. Это будет совсем не Ъ или вполне нормально поставить x86 и плюнуть на 64 бита? Не думаю, что на моем железе производительность прямо таки сильно упадет... Зато, проблем, думаю, будет меньше. Я так понимаю, не у меня одного возникают проблемы. Судя по базе пакетов поддержка у этих двух архитектур примерно одинаковая, но анстейбл анстейблу, всё-таки, рознь...

news, dispatch-conf... Правда, немного поторопился. Тут моя вина.

>Зато, проблем, думаю, будет меньше

разницы в стабильности нет никакой абсолютно

напротив, слышал, что некоторые программы первым делом тестируются на amd64, потому как более перспективная платформа по сравнению с x86