Daniel Robbins хочет вернуться в Gentoo Foundation

> :) Ты другие дистрибутивы то видел?

>Я с тормознутой генты ушел, "заточенной под железо" с дикой фрагментацией после лет постоянных компиляций и с тормозным emerge который рисует /-\- минуты две перед тем как начать собирать.

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

P.S. Думаеш, после лет работы с Убунту и постоянных обновлений фрагментация будет меньше?

>P.S. Думаеш, после лет работы с Убунту и постоянных обновлений фрагментация будет меньше?

Кстати, да, чего-то я протормозил и повёлся :) Какая разница, откуда в /usr/ пишутся *.so, распаковываются из архива или копируются из раздела со /var/tmp/portage. Фрагментация будет совершенно одинаковая на равное число апгрейдов/обновлений/фиксов.

> мне кривизну рук ещё некуда было применить > Только что установленная бубунта

Разве при установке ручки не используются? Тады ой, тады понятно... ;)

Настраивал оперу как? Переносом "/home/balancer/.opera/" из генты?

> Она, видишь ли, и в состав Gentoo не входит.

Потому все претензии либо к своим ручкам, либо к разработчикам оперы, до тех пор пока не доказано иное. Или с такой формулировкой не согласен? ;)

> Это депутатский спич на тему "как бы стало б хорошо, если б было б зашибись"?

Это то, к чему стремятся Debian и Ubuntu, пока гентушники городят
костыли и бантики для облегчения рабского ручного труда по сборке
программ из исходников и усовершенствуют напильники revdep-rebuild и emerge -e world.

> Что делает в этой каше mplayer, который авторы просят собирать из исходников?

Ссылку! mplayer выбирает оптимизацию под процессор динамически! И
openssl выбирает. SHA1 в OpenSSL автоматически задействует SSE2 при
наличии оного(за счет ассемблерной вставки, а не за счет -msse -mmmx
которые на x86 не дают ровным счетом ничего), плюс openssl
использует hwcap для автовыбора оптимизированных под процессор сборок
с помощью возможностей стандартного линуксового загрузчика.

libssl.so.0.9.8 (libc6, hwcap: 0x0008000000008000) => /usr/lib/i686/cmov/libssl.so.0.9.8
libssl.so.0.9.8 (libc6, hwcap: 0x0004000000000000) => /usr/lib/i586/libssl.so.0.9.8
libssl.so.0.9.8 (libc6, hwcap: 0x0002000000000000) => /usr/lib/i486/libssl.so.0.9.8

Вот так, учись, студент какие возможности заложены в систему и программы
и как эти программы самооптимизируются и выбирают оптимальный вариант без
тяжелого ручного конвейерного труда гентушников-оптимизаторов,
верящих в сотни процентов прироста производительности от "заточки подсвое железо".
Это называется умной автоматикой. А гики пусть верять в чудодейственную силу
-mmmx -msse, продолжают компилировать freetype с BCI который в бинарных
системах уже так и собран, оптимизировать самооптимизирующиеся под
SIMD openssl и mplayer,
ловить преимущества от MMX которое в ядре не используется,
пытаться побороть генные тормоза FF и OO не установкой планки памяти, а компилирингом по 6 часов. Ха-ха-ха. ;)

ЗЫ
Плять как вы можете только с этими красозелеными буквами с BCI SPR работать...

> gcc -march=athlon64 -c ./test.c -S -o ./test_mmx.S gcc -m32 -march=prescott -mfpmath=sse -c ./test.c -S -o ./test.S

Ха-ха-ха, ламер! ))) -march=athlon64 - это не x86 и это прекрасно видно по регистру RAX )))))) Любой бинарный дистрибутив уже заточен под AMD64, так что оптимизировать на AMD64 гентуу - мартышкин труд. )))) -mfpmath=sse отнюдь не эквивалентно -mmmx -msse про которые была речь и не ВЕКТОРИЗУЕТ, т.е. теряется сам смысл использования SIMD, который эффективен только для операций над векторами, а с со своим fpmath=sse ты используешь блок SSE в качестве обычного FPU, производя скалярные операции :) На вот про addsd почитай: http://www.lrz-muenchen.de/services/software/programmierung/vtune/merged_olh/...

> А, я понял! Под виндой скрипт не удобно запускать...

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

>Разве при установке ручки не используются?

В моём понимании "прижодить ручки", это, как минимум, что-то подкрутить в тонкостях пакетного менеджера, как максимум - самопальный ebuild (в отсутствии портежа - вручную ./configure && make && make install), Если же ставится что-то пакетным менеджером - то это не ручками. А пакетным менеджером.

>Настраивал оперу как? Переносом "/home/balancer/.opera/" из генты?

Не держи за идиота, настройки никакие не переносились. Вообще. Это раз. А два - то, что ты не в теме. Нативность интерфейса Оперы никак не зависит от юзеровского конфига. Можно только переключить - нативный / оперовский.

>Потому все претензии либо к своим ручкам, либо к разработчикам оперы

С таким же успехом - это проблема мэйнтейнера, собиравшего соответствующий репозиторий в Убунте. При чём, я считаю, это наиболее вероятная причина. Вот если б я её вручную ставил, скачав с их сайта...

> Кстати, да, чего-то я протормозил и повёлся :) Какая разница, откуда в /usr/ пишутся *.so, распаковываются из архива или копируются из раздела со /var/tmp/portage. Фрагментация будет совершенно одинаковая на равное число апгрейдов/обновлений/фиксов.

Сравни число устанавливаемых *.so и число исходников плюс получаемых в ходе компиляции объектников плюс полученных *.so, которые устанавливаются между этими временно распакованными исходниками, которые затем удаляются и вопросы отпадут.

>которые устанавливаются между этими временно распакованными исходниками

У тебя /var в том же разделе, где /usr? Ну, ты ССЗБ :) Скажем, для /usr не нужен atime, а для /var он очень полезен. У тебя /usr смонтирован с atime? :D

>xeffects, откуда я обычно брал патчи на cairo и libXft (freetype уже не нужно патчить, там всё что надо - в официальном портеже) сейчас не работает, зато найдет хороший font-overlay https://boniek.homelinux.org/svn/repos/font-overlay/trunk/ (прописал его в layman) KRoN73 ***** (*) (15.01.2008 13:41:12)

Спасибо за ссылку

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

На x86 не генерит. А на AMD64 смысла оптимизировать нет, т.к. в любом бинарном дистре итак все оптимизировано искаропки и судя по всему с автовекторизацией. И еще, прирост от тупой автовекторизации не дотягивает до ассемблерных вставок и наблюдается только на сферических конях в вакууме. А взять, например, openssl, собрать под i686 и собратьпод какой-нибудь prescott с -fpmath=sse и -ftree-vectorize и прирост, а иногда и падение скорости по openssl speed будет в пределах погрешности.

>Сравни число устанавливаемых *.so и число исходников плюс получаемых в ходе компиляции объектников плюс полученных *.so, которые устанавливаются между этими временно распакованными исходниками, которые затем удаляются и вопросы отпадут.

Все временные файлы обязательно будут разбросаны в рпзных местах диска?

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

Нет, ещё раздел шривтов, плиз.

> А тут под дебианщиков косят бубунтологи, а им что BSD-style, что SV -- одинаково... "оптимально"...

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

USE="-religion 2nd_convolution" emerge a110c-mosk

ЗЫ

В Debian/kFreeBSD sysv, елси кто-то ниасилил гугля: http://ftp.debian-ports.org/debian-kfreebsd/pool/main/s/sysvinit/

> Какой-то анонимус(ы) выдумал про векторные расширения gcc

Учи матчасть. http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html Только такую фичу мало кто использует...

> а я показал наглядный пример (который уже был кем-то запощен на ЛОРе ранее) как раз для сравнения когда gcc генерит какой код.

А я показал тебе, что на x86 это не работает, даже если выбрана march=pentium4 и заданы -mmmx и -msse. Для AMD64, видимо, по умолчанию включили автовекторизатор, поэтому SSE инструкции генерятся. Но раз они генерятся по умолчанию, значит в любом бинарном дистре для AMD64 уже все заоптимизировано и под AMD64 и под SSE насколько хватает сил у gcc, так что гента идет втопку. А gcc - хреновый оптимизирующий компилятор. В области оптимизации кода ему далековато до icc, который и автоматически векторизует на x86 и более эффективно использует регистры(ни разу не видел чтобы gcc использовал xmm4 и выше, а icc собирает код который активно использует все SSE-регистры).

>ЗЫ

>В Debian/kFreeBSD sysv, елси кто-то ниасилил гугля: >http://ftp.debian-ports.org/debian-kfreebsd/pool/main/s/sysvinit/

А я уже думал что не дождусь ответа ;). А ответ то был элементарныым: если в Debian GNU/Linux уровни запуска сделаны в стиле System V, то и в Debian на ядре BSD они должны быть SysV, иначе майнтейнерам придётся вносить изменения в многие пакеты, прописывающие себя в загрузку. ;)

P.S. Рад, что Убунтовщики гаконец осилили Google...

>Нет, ещё раздел шривтов, плиз.

Я правильно понял, что тебе с сабноута?

Section "Files" RgbPath "/usr/share/X11/rgb" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/OTF" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/CID/" FontPath "/usr/share/fonts/100dpi/" FontPath "/usr/share/fonts/75dpi/" EndSection

Оно? Такое же, как на десктопах. Т.е. фишка в том, что я с настройками вообще не мудрил, просто при сборке на ставил лишнего и всё собирал с USE="minimal".

сенкс

> В моём понимании "прижодить ручки", это, как минимум, что-то подкрутить в тонкостях пакетного менеджера

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

> А два - то, что ты не в теме.

Да ну? ;) Мне для унификации интерфейса достаточно было зайти в меню "Инструменты - Внешний_вид" и кутишные настройки сразу подхватились, но не в теме почему-то именно я... ;)

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

> С таким же успехом - это проблема мэйнтейнера, собиравшего соответствующий репозиторий в Убунте.

Тогда, уважаемый, скажите, из какого репозитария вы ставили оперу, и кто этот репозитарий поддерживает? Смотрю у себя - разработчик: Opera Packaging Team <packager@opera.com>. У тебя так же? И виноват по прежнему "стабильный и проверенный дистрибутив"? ;)

> Вот если б я её вручную ставил, скачав с их сайта...

Честно говоря, я не в курсе. Пакет, который ты скачиваешь вручную как-то отличается от пакета, установленного из репозитария?

это чтож надо сделать такое, чтоб убунта так заглючила? да еще и опера?
может не надо было её по привычке собирать, а apt-get install opera?
Cломать можно всё что угодно.

ЗЫ. кто такой Симантик? Это что-то связаное с антивирусами кажется?

> Гы. А в Убунте шрифты-то - без патентованного SPR. Корявенькие...

А включенный по умолчанию TT_CONFIG_OPTION_BYTECODE_INTERPRETER это по-твому что? А фича "оптимизированные для ЖК шрифты" в настройках? Иди учи матчас по убунте. :)

> А вот в Убунте после установки из Синаптика, что 9.25, что бета 9.50 - имеют чудовищные motiff-like стиль?

У мну в 7.10 нормальный qt-шный вид. :) В opera.list: "deb http://deb.opera.com/opera/ sid non-free"

> Почему установка flashplugin-nonfree обламывается после скачивания с офсайта с несоответствием контрольной суммы.

Действительно. Потому что адобы что-то затроянили. Раньше все нормально устанавливалось. Косяк.

> Наконец, почему она так тормозит на интенсивных дисковых операциях?

Индексатор отключен?

> Почему половина плагинов разного калибра часов к gDesklets при запуске выдают ошибки. Половина оставшейся половины не конфигурится и вешается при попытке отконфигурить.

Какие плагины так и работают. Если софт кривой, то это проблемы этого софта, а не дистрибутива.

> И ЭТО вы называете стабильным и проверенным дистром?? :D :D :D

С оперой никаких проблем нет, хотя она и в дистре то не поставляется. Флеш действительно не ставится, раньше прекрасно работал - не обновили контрольную сумму зарояненной проприетарщины. А если с gdesklets проблемы, то надо винить авторов. Да, это одна из лучших систем для десктопа, на порядки лучше для ПОЛЬЗОВАТЕЛЯ, чем гента, которую кроме задротов никто и не осилит, но и у задротов иногда заканчивается терпение постоянно бороться с косяками после каждого второго обновления.

> Однако, на P75/32RAM Gentoo вполне себе живёт. Хотя и не с OOo. Как на таком железе Ubuntu бегать будет? ;)

Это из разряда "натяни штаны через голову". Да кому это #%^ за сто рублей нужно на десктопе? Сутками поди компилируешь систему при обновлениях? Или к этой машине приложен core2quad, специально для сборки обновлений системы? Просто мегарешение.

>TT_CONFIG_OPTION_BYTECODE_INTERPRETER

Опять не в теме. Какое отношение BCI имеет к патентованному spr?

> А ещё через полгодика - ну сделаю "дефраг мувом" :)

Вобщем, система на любителя возиться с компиляцией и дефрагментацией. Чистки реестра в генте еще не сделали?

> Открытие - Gentoo - многозадачная система. И пока "emerge рисует /-\-"

... в убунте уже стоит пакет.

> можно пойти на ЛОР, послушать музыку, поредактировать документ в OOo, попрограммировать в Eclipse....

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

> Это - да. Но у меня этому /usr - около полугода.

А у мну 4 года было. И еле ползало

>Или к этой машине приложен core2quad, специально для сборки обновлений системы?

А прчитать слабО? Или мысль, что если эта машинка служит для халявного дистанционного управления большой, то на этой большой можно для маленькой бинарники собирать в голову тебе не приходит? :D

> И, вообще, вопрос-то был не том, зачем оно нужно, а в том, что "Как не твикай генту..." - повторсь, Убунту пойдёт на таком железе? :)

LiveCD есть. Возьми да попробуй. А OOO пойдет на таком железе? Вообще-то речь была про тормозные OOo и FF, которые на 512 RAM на P4 3GHz тормозят и на убунте и в дебиане и на генте. а на таком ужасе, пентуме первом, я вообще не представляю что будет.

>Только для того, чтобы попрограммировать в Eclipse надо его собрать.

$ sudo qlop -gH eclipse-sdk

...

eclipse-sdk: Wed Oct 17 06:15:51 2007: 13 minutes, 6 seconds

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

...

В общем, пока вы теоретизируете - я сегодня на практике с Бубунтой наигрался, дальше некуда :D И, ладно я, считайте меня лицом ангажированным, но вот жена, совершенно далёкая от всех этих компьютерных споров не понимает, как это так, в меню могут быть часть пунктов переведёнными, а часть - нет :) И почему её любимая Опера - такая уродливая...

>LiveCD есть. Возьми да попробуй.

Гы. У Тошиба Либреттно нет загрузки с CD. Это сабноут 1997-го года выпуска.

>Вообще-то речь была про тормозные OOo и FF, которые на 512 RAM на P4 3GHz тормозят

Про 512Мб не скажу, но на 1024 OOo летает. И памяти свободной остаётся заметно более 512Мб. Запускается под рабочей нагрузкой за 9 секунд против 14 секунд, скажем, у Word 2003 :) или аж всего 6 секунд у KWord (который потом даже бордюры у таблиц не показывает). Не вижу принципиальных тормозов.

FF - этот да, нетороплив. Но только в сравнении с Оперой. Сам по себе нынешний Фокс без Cairo довольно шустрый.

Вот на P75 с 32Мб - там Фокс тормоз. Грузится до 4-х минут и страницы открывает по 40..60 секунд.

> С таким же успехом - это проблема мэйнтейнера, собиравшего соответствующий репозиторий в Убунте. При чём, я считаю, это наиболее вероятная причина. Вот если б я её вручную ставил, скачав с их сайта...

А кто мешает? deb http://deb.opera.com/opera/ sid non-fr

> У тебя /var в том же разделе, где /usr?

Да, на десктопе все на одном, чтобы не иметь гиморроя с закончившимся местом на /var когда на /usr его еще дофига.

> Скажем, для /usr не нужен atime, а для /var он очень полезен. У тебя /usr смонтирован с atime? :D

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

>Ха-ха-ха, ламер! ))) -march=athlon64 - это не x86 и это прекрасно видно по регистру RAX ))))))

Здравствуй ещё один совершенно другой анонимус! Опусти глаза ещё на строчку ниже, и увидь "gcc -m32 -march=prescott -mfpmath=sse -c ./test.c -S -o ./test.S " который прекрасно видно по

+ movsd .LC0, %xmm0 + movsd %xmm0, -8(%ebp)

>-mfpmath=sse отнюдь не эквивалентно -mmmx -msse про которые была речь и не ВЕКТОРИЗУЕТ, т.е. теряется сам смысл использования SIMD, который эффективен только для операций над векторами, а с со своим fpmath=sse ты используешь блок SSE в качестве обычного FPU, производя скалярные операции :)

Давайте начнём с начала. Две приведённые выше инструкции являются расширенными иснтрукциями и входят в набор SIMD инструкций. (хотя утверждалось "На x86 никаких SSE-инструкций не появляется, MMX тем более сами по себе не появятся,") Вы можете использовать ключик -O2 и посмотреть как измениться ассемблерный код. Также можете поставить не просто a+=1.0 а r+=a*1.2, или a=1.1*1.2... и т.п.

Если хотите использовать сопроцессор по максимуму, то придётся писать ассемблерные вставки, потому как компилятор не может оптимизировать код до упора, это должен делать человек. USE-флаги -mmx -sse как раз и включают такие ассемблеррные вставки, если они есть. Теперь давайте угадаем, есть ли такие вставки в бинарных 32битных дистрибутивах?

Также интересно узнать, почему SIMD эффективен только для операций над векторами (рекомендую сравнить количество инструкций в цикле с -mfpmath=sse и без).

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

Нет, я серьёзно. Вам, о совершенно другой анонимус, так тяжело выполнить скрипт и посмотреть как изменяется ассемблерный код в зависимости от тех или иных условий! Из чего можно сделать вывод, что матчасть Вам не очень помогла

> А ответ то был элементарныым: если в Debian GNU/Linux уровни запуска сделаны в стиле System V, то и в Debian на ядре BSD они должны быть SysV, иначе майнтейнерам придётся вносить изменения в многие пакеты, прописывающие себя в загрузку. ;)

И это теоретически возможно. Потому что с дяром FreeBSD мантейнерам отнюдь не теоретически придется столкнуться с отсутствием ALSA, IML, netfilter и многих других Linux-only фич и вносить изменения в пакеты.

>>TT_CONFIG_OPTION_BYTECODE_INTERPRETER

>Опять не в теме. Какое отношение BCI имеет к патентованному spr?

Да, немного не в теме. А разве BCI сам по себе не запатентован? Иначе зачем эти патчи, включающие выключенный BCI, который как раз и используется для субпиксельного рендеринга?

Ппц 20 страниц нафлудили. Сам гентушник но религиозных фанатеГов невоспринимаю. До помутнения в глазах доказывать что Генту рулеЗ, а убунта(дебиан/суся и т.д.) - сакс, непонятно зачем это? Да пофик мне какой такой аптгет крутой, и если кто-то считает портаж фуфлом, то и флаг ему в руки, ибо взаимно:) а вот только возможность возврата Даниеля привела к возобновлению новостей на gentoo.org (это аж с 15 октября) это факт и это по-теме. Знач нужен папик.

> А прчитать слабО? Или мысль, что если эта машинка служит для халявного дистанционного управления большой, то на этой большой можно для маленькой бинарники собирать в голову тебе не приходит? :D

А ltsp, который есть в репах тебе в голову не приходило?

> В общем, пока вы теоретизируете - я сегодня на практике с Бубунтой наигрался, дальше некуда :D И, ладно я, считайте меня лицом ангажированным, но вот жена, совершенно далёкая от всех этих компьютерных споров не понимает, как это так, в меню могут быть часть пунктов переведёнными, а часть - нет :)

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

> как это так, в меню могут быть часть пунктов переведёнными, а часть - нет :)

Да точно также как переведенные наполовину wiki, заброшенные на половине переводы документации, смесь русско-английского на сайтах даже таких контор как Novell и прочий опенсорсный бардак. А у linuxdcpp в генте все ли пункты меню переведены?

>Учи матчасть. http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html Только такую фичу мало кто использует...

Ага. Ситуация начинает проясняться. Т.е. под "На x86 никаких SSE-инструкций не появляется, MMX тем более сами по себе не появятся," на самом деле подразумевалось использование gcc по умолчанию некоторого набора инструкций, которые работают с "векторными" данными! Так об этом надо было сразу говорить, а то понимаешь я два дня тут голову ломаю!

>А я показал тебе, что на x86 это не работает, даже если выбрана march=pentium4 и заданы -mmmx и -msse.

Если смысл тот что описан по ссылке, то да я с этим согласен.

>Для AMD64, видимо, по умолчанию включили автовекторизатор, поэтому SSE инструкции генерятся.

Тут опять начинается что-то непонятное. Или movldp как раз и есть та самая "векторная" инструкция?

>А gcc - хреновый оптимизирующий компилятор.

Естественно, что лучше руками ;)

>ни разу не видел чтобы gcc использовал xmm4 и выше, а icc собирает код который активно использует все SSE-регистры

Хотите посмотреть?

#!/bin/bash
cat << CODE > ./test.c
double test() {
double a,b,c,d,e,f,g,h,i,r;
a=b=c=d=e=f=g=h=r=5;
for(i=0;i<10;i++) {
a+=1.4*1.1;
b+=1.4*1.2;
c+=1.4*1.3;
d+=1.4*1.4;
e+=1.4*1.5;
f+=1.4*1.6;
g+=1.4*1.7;
h+=1.4*1.8;
r+=a+b+c+d+f+g+h;
}
return r;
}
CODE
gcc -march=athlon64 -O2 -c ./test.c -S -o ./test_mmx.S
gcc -m32 -march=prescott -mfpmath=sse -O2 -c ./test.c -S -o ./test.S
diff -uN ./test_mmx.S ./test.S

>в меню могут быть часть пунктов переведёнными, а часть - нет

система>локализации>галочку поставьте напротив Russian. Немного подождать и всё будет на русском. Вам не приходило в голову что этот диск, который вам доставили совершенно бесплатно, не предназначался исключительно для России? Соответственно не все пакеты переведены на наш язык. Согласитесь - 700Mb не так много, чтобы тратить это место на сотню другую локализаций.

>И почему её любимая Опера - такая уродливая...

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

>До помутнения в глазах доказывать что Генту рулеЗ, а убунта(дебиан/суся и т.д.) - сакс, непонятно зачем это?

И я не знаю :) Тут один товарищ просто упорно, страниц на 15 доказывал, что Генту - это дерьмо :D А что Убунту - сакс, об этом только на последней странице и только по свежим впечатлениям, а не по сугубому теоретизированию...

>Ты б лучше просятил человека как в генте происходит установка программ и обновление консольным емержем, который вообще не русифицирован.

А ей-то это зачем? Это моя работа. Ей важно, чтобы нормально работали программы, которые я поставлю. А этого - нет.

>Да точно также как переведенные наполовину wiki

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

>система>локализации>галочку поставьте напротив Russian. Немного подождать и всё будет на русском. Вам не приходило в голову что этот диск, который вам доставили совершенно бесплатно, не предназначался исключительно для России?

М... Действительно, помогло. Спасибо. В голову не приходило, так как диск не "бесплатно доставляли", а я выкачивал, при установке выбирал "русский", после установки - провёл полное обновление... В Gentoo в таких случаях _всё_ оказывается корректно русифицировано :)

...

И удивительно, что _частичная_ русификация меню была. Не было б её вовсе - тогда была б мысль хотя бы причины поискать :)

>>И почему её любимая Опера - такая уродливая...

>это, извините, только у вас.

Ну, вот так оно, с Оперой у меня... И с падением плагинов gDesklet'а. И с непатентованным рендерингом.

> И я не знаю :) Тут один товарищ просто упорно, страниц на 15 доказывал, что Генту - это дерьмо :D

Ну-ну. А другой товарисч с точно таким же упорством разве не доказывал что все что не генту - отстой.

Теперь вот и Вы присоединились к его высказываниям. :(

> Расскажи, плиз, где ты увидел лохматые буквы в OOo? И с какой целью нужно его пересобирать? 
> Вот скриншот бинарного OOo: http://slil.ru/25358751

> На подавись:
> Patch1: freetype-2.1.10-rh-enable-ft2-bci.patch
> Patch2: ft2demos-2.1.10-rh-makefile.patch
> Patch3: freetype-2.1.10-cvsfixes.patch
> Patch4: freetype-2.1.10-fixautofit.patch
> Patch5: freetype-2.1.10-memleak.patch
> Patch6: freetype-2.1.10-fixaliasing.patch
> Patch7: freetype-2.1.10-fixkerning.patch
> Patch8: freetype-2.1.10-xorgfix.patch
> Patch10: freetype2-bitmap-foundry.patch
> Видишь bci патчи или нет? Всё по умолчанию включено.

1) Ты слеп как крот. Купи ачки.

2) Тебе написали уже про BCI и SPR. Запусти xmag, если ачков нет.

3) Ты ниасилил разницу между "./configure --with-system-freetype",
"#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER" и командой patch.

> Опусти глаза ещё на строчку ниже, и увидь "gcc -m32 -march=prescott -mfpmath=sse -c ./test.c -S -o ./test.S " который прекрасно видно по

Да, с -fpmath=sse все FPU инструкции заменяются на скалярные SSE-инструкции(Use scalar floating point instructions present in the SSE instruction set). Какое это дает преимущество? SIMD был придуман для выполнения параллельных операций над несколькими скалярами, т.е. для векторных операций. Если блок SSE используется как FPU то нафиг это нужно?

> Давайте начнём с начала. Две приведённые выше инструкции являются расширенными иснтрукциями и входят в набор SIMD инструкций. (хотя утверждалось "На x86 никаких SSE-инструкций не появляется, MMX тем более сами по себе не появятся,")

Хорошо. Исправляюсь. MMX инструкции сами не генерятся. Скалярные SSE инструкции, использующие блок SSE как FPU, генерятся если использовать -mfpmath=sse(включено для x86-64 gcc по умолчанию). Преимущества SIMD не используются, следовательно увеличение произв-ти сомнительно.

> Если хотите использовать сопроцессор по максимуму, то придётся писать ассемблерные вставки

О чем и была речь.

> USE-флаги -mmx -sse как раз и включают такие ассемблеррные вставки, если они есть. Теперь давайте угадаем, есть ли такие вставки в бинарных 32битных дистрибутивах?

Есть.

$ objdump -d /usr/lib/i686/cmov/libcrypto.so.0.9.8|grep xmm|head 40154: 66 0f ef c0 pxor %xmm0,%xmm0 40158: 66 0f ef c9 pxor %xmm1,%xmm1 4015c: 66 0f ef d2 pxor %xmm2,%xmm2 40160: 66 0f ef db pxor %xmm3,%xmm3 40164: 66 0f ef e4 pxor %xmm4,%xmm4 40168: 66 0f ef ed pxor %xmm5,%xmm5 4016c: 66 0f ef f6 pxor %xmm6,%xmm6 40170: 66 0f ef ff pxor %xmm7,%xmm7 52be1: f3 0f 6f 02 movdqu (%edx),%xmm0 52be5: f3 0f 6f 4a 10 movdqu 0x10(%edx),%xmm1

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

> Также интересно узнать, почему SIMD эффективен только для операций над векторами (рекомендую сравнить количество инструкций в цикле с -mfpmath=sse и без).

Потому что Single Instractions Multiple Data. Одна операция одновременно производится над двумя или четырьмя парами чисел. А в случае скалярных операций операция проводится только над одной парой, а это классическая целочисленная либо FPU арифметика, принцип SIMD курит в сторонке.

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

Приведенный выше скрипт с указанными ранее флагами(изначально про -fpmath упомянут не был) к появлению SIMD инструкций на x86 НЕ приводил: http://www.linux.org.ru/view-message.jsp?msgid=2406675&page=16#2413401 http://www.linux.org.ru/view-message.jsp?msgid=2406675&page=16#2413411

> Теперь вот и Вы присоединились к его высказываниям. :(

Я могу пересматривать своё мнение :) Уже одно только "исправление" русификации Tellico, по крайней мере в глазах жены Убунту немного оправдало. Если удастся добить (_штатными средствами_ :D) фейс Оперы и прикрутить патентованный SPR - то, по крайней мере, у меня будет время вдоволь и не бессмысленно поиграть с Убунтой. Пока - отношение к ней всё равно всё ещё негативное. Но посмотрим...

>Тут один товарищ просто упорно, страниц на 15 доказывал, что Генту - это дерьмо :D

Если "этот тролль" подразумевает меня, то напомню, что в самом начале я писал, что дерьмо это не Генту, а его фанаты, не осилившие нормальные дистрибутивы и сующие свой лего-конструктор куда попало. Just for fun - сколько угодно пусть компиляют, а когда за ними приходится их художества убирать - неприятно.

> Плять как вы можете только с этими красозелеными буквами с BCI SPR работать...

Так они только у косолапых бубунтологов "красозелёные".

>Если блок SSE используется как FPU то нафиг это нужно?

Предлагаю не теоретизировать, а посмотерть и сравнить.

>Преимущества SIMD не используются, следовательно увеличение произв-ти сомнительно.

Все, или некоторые всё же будут использоваться? Опять же рекомендую сравнить.

>$ objdump -d /usr/lib/i686/cmov/libcrypto.so.0.9.8|grep xmm|head 40154

Пожалуйста, назовите пакет которому принадлежит эта библиотека (желательно также указать дистрибутив).

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

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

>А в случае скалярных операций операция проводится только над одной парой, а это классическая целочисленная либо FPU арифметика, принцип SIMD курит в сторонке.

Не подскажите, зачем же эти скалярные операции включили в набор инструкций SIMD?

>Приведенный выше скрипт с указанными ранее флагами(изначально про -fpmath упомянут не был) к появлению SIMD инструкций на x86 НЕ приводил:

А "как изменяется ассемблерный код в зависимости от тех или иных условий" Вам не интересно? Теоретизируете и считаете что полностью поняли как работает процессор и как сишный код преобразуется в ассемблерный?

Тот скрипт был приведён в качестве примере, что если пакеты собраны "Целевая архитектура: i486-linux-gnu " то некоторые оптимизации, и расширения процессора не будут задействованы, код будет несколько больше а цикл будет выполняться ещё дольше. Если же опции и платформа выбрана верно, то получается более эффективный код.

>http://www.linux.org.ru/view-message.jsp?msgid=2406675&page=16#2413401 http://www.linux.org.ru/view-message.jsp?msgid=2406675&page=16#2413411

В заголовке поста присутствует ссылка # которую и надо было скопировать. А то у меня, например, страниц только 12...

> 1) Ты слеп как крот. Купи ачки.

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

> 2) Тебе написали уже про BCI и SPR. Запусти xmag, если ачков нет.

Поддержка BCI в freetype есть.

> 3) Ты ниасилил разницу между "./configure --with-system-freetype", "#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER" и командой patch.

$ zcat openoffice.org_2.3.0-1ubuntu5.3.diff.gz |grep with-system-freetype|wc -l 13

$ grep system-freetype openoffice.org-2.3.0/debian/changelog - system-freetype.diff: Fix for Woody backport - use -lfreetype to link - system-freetype: merged patch; use system freetype and fix for freetype - gui-ft-dynlink-system, freetype_2_1_7: merged into system-freetype [RE] - --with-system-db --with-system-nas --with-system-freetype (except on

Стандартный сорс. Так что компелировать, красноглазик, солнце еще высоко! :)