форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
Сообщение от opennews (??) on 31-Окт-09, 23:11
Оценка (http://www.linux-mag.com/id/7574/)  влияния флагов оптимизации GCC на производительность Gentoo Linux. URL: http://www.linux-mag.com/id/7574/ Новость: http://www.opennet.dev/opennews/art.shtml?num=24066
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Оценка влияния флагов оптимизации GCC на производительность ..."		–13 +/–
Сообщение от Аноним (??) on 31-Окт-09, 23:11
казалось бы код один а результаты такие разные, как может один линукс проигрывать другому линуксу в 2 раза?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Оценка влияния флагов оптимизации GCC на производительность ..."		+9 +/–
	Сообщение от hatewindows on 31-Окт-09, 23:33
	Торавищ анонимус прочтите ман к GCC и значение флагов оптимизации, вопросы уйдут. Ну и оптимизация системы, компиляцией ядра под конкретное железо, конечно. Хотя бы тут http://www.insidepro.com/kk/231/231r.shtml
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Оценка влияния флагов оптимизации GCC на производительность ..."		+4 +/–
	Сообщение от pavlinux (ok) on 01-Ноя-09, 08:14
	Можно выпить литр водки, а можно литр подогретой водки. Вроде везде водка, а какой разный результат! :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
Сообщение от аноним on 01-Ноя-09, 00:06
Ну наконец-то то, о чем все вобщем-то всегда знали или предполагали, облекли в удобную для восприятия форму. Разница местами в разы. Учитывая другие проблемы бинарных пакетных систем (например, прибитые гвоздями зависимости и библиотеки - а это на мой взгляд даже важнее производительности), уделом их остаются совсем слабые машины, а также жертвы FUD'а, которые считают что собирать из исходников - это сложно или медленно.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от Den (??) on 01-Ноя-09, 00:20
	Не сложно, но некоторых железках очень даже не быстро...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от аноним on 01-Ноя-09, 00:59
	Я и говорю, бинарщина - только для этих "некоторых железок".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 00:34
	>Ну наконец-то то, о чем все вобщем-то всегда знали или предполагали, облекли >в удобную для восприятия форму. Разница местами в разы. Учитывая другие >проблемы бинарных пакетных систем (например, прибитые гвоздями зависимости и библиотеки - >а это на мой взгляд даже важнее производительности), уделом их остаются >совсем слабые машины, а также жертвы FUD'а, которые считают что собирать >из исходников - это сложно или медленно. тут очень странный бенчмарк: во-первых, разные релизы той же бунты и федоры в тех же форониксовских тестах иногда отличаются гораздо больше, во-вторых, разные версии ядра, а в третьих... apparmor в Убунте отключен :)?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от pavel_simple (ok) on 01-Ноя-09, 00:46
	>Ну наконец-то то, о чем все вобщем-то всегда знали или предполагали, облекли >в удобную для восприятия форму. Разница местами в разы. Учитывая другие >проблемы бинарных пакетных систем (например, прибитые гвоздями зависимости и библиотеки - >а это на мой взгляд даже важнее производительности), уделом их остаются >совсем слабые машины, а также жертвы FUD'а, которые считают что собирать >из исходников - это сложно или медленно. ааа... теперь по пунктам.... 1. Всё что касается кодеков единственно заметная разница в mencoder'е -- да за последний год я перекодировал аж целый гигабайт видео, вот интересно насколько я отстал ут гентушников на 2 минуты? на три? -- вот эта потеря времени !!! 2. apache compilation -- у меня Debian lenny - на кой хер я буду перекомпилячить апач?, остальные компиляции идут туда-же т.е. в /dev/null 3. игры? а что гентушники ещё и играют? и сколько они тратят на доведение системы до состояния game-station? 4. graphics-magic ??? -- берем время потраченное на компиляцию gentoo'шниками и вычитаем её из результатов разницы между gentoo и ubuntu , и получаем.... можно 5 лет не обращать внимание на разницу результатов. 5. ray-tracing ... ах -- да тут аж 8 пакетов пересобрать... ёкмакарёк... и что из-за этого теперь не использовать пакетный дистрибутив? а если подсчитать сколько людей реально проводят подобного рода расчёты... результат можно списывать на нет. 6. тестирование на gtkperf мне показалось просто редким дибилизмом, и нет -- я не разу не видет чтобы у меня на рабочем столе было больше 1000 кнопок или других элементов управления gtk. остальное даже смотреть не стал... в итоге небольшое ИМХО для любителей меряться всем чем попало (подходящим и не очень) очередной тест говорит о том что gentoo это gentoo а ubuntu это ubuntu, а что разные флаги оптимизации приводят к разным результатам, что вобщем-то любой здравый человек и так понимает. P.S. сравнение изначально проводится с непонятными входящими, как то версии библиотек, DE, разные ядра, разные версии дров видео - короче не тест а говно
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Оценка влияния флагов оптимизации GCC на производительность ..."		+3 +/–
	Сообщение от anonymous (??) on 01-Ноя-09, 00:49
	Только идиоты из Red Hat этого не знают, знай себе бабло стригут, в ядро вкладывают и прочие проекты. Когда тебе позвонит совершенно незнакомый человек и попросит разобраться с неработающей но "очень правильно скомпилированой" программкой, и выяснится, что причина сбоя в том, что во время компиляции у того гражданина сбойнула память. Или еще хуже - его компилятор был тоже пересобран c такими модными флагами, которые почему то создатели компилятора убрали так далеко что даже не попало в -О3. Одно дело твой личный комп с порнухой который можно форматировать 10 раз на дню и никому от этого не холодно ни жарко включая владельца, и совсем другое дело реальная жизнь и реальные прикладные задачи, от стабильности работы которых зависят многие. Кстати, удачи с -flto - fwhole-program, с ними то точно зарулишь всех убунтоводов!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Оценка влияния флагов оптимизации GCC на производительность ..."		+8 +/–
	Сообщение от anonymous (??) on 01-Ноя-09, 02:56
	Ну ты точно неадекват. Я тебе говорю, что когда пользователи компилируют все пакеты на своем непровереном железе то результат к сожалению получается разный и практически невозможно разобраться за приемлемое время с сложными ошибками . И наоборот, c бинарными пакетами, которые компилируются на специaльных серверах у которых хоть худо бедно память с проверкой четности и прочие недешевые заморочки хоть как то можно положиться на результат работы компилятора. И что более важно - к тысячам клиентов попадают бинарники бит в бит одинаковые, и багрепорты от них имеют намного большую ценность чем твои коммюнике типа "уменяниработает флаги -O100500 тачка новая вчера купил памагите". GCC - это охренено сложная программулина, настолько здоровенная что уже не найти 1 человека который мог бы охватить все модули все десятки а теперь уж и сотни проходов и не говоря уж о комбинациях опций командной строки. Если ты в ней шаришь (всяко бывает) - компилируй сам, но не кричи о том что все вокруг должны так же поступать потому как твоя 1 программа заработала на конеретно твоем компе на 1% быстрее. Еще че то про Ынтырпрайс трендит...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от andrew (??) on 01-Ноя-09, 04:05
	могу поведать тебе свою историю. я начал ставить генту вчера. сегодня к вечеру я уже на ней фильмец посмотрел. и все у меня компилилось замечательно, никаких сбоев. (даже с use вроде разобрался 8) ) а о том, чтобы компиляция работала уже позаботились разработчики. так что гента - это простая и удобная штука на самом деле, просто надо иметь за плечами какой-то опыт.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от iZEN (ok) on 01-Ноя-09, 09:04
	>я начал ставить генту вчера. сегодня к вечеру я уже на ней фильмец посмотрел. Процессор, память, диски? FreeBSD от нуля до "фильмец посмотреть" на Athlon X2 3800+/2ГБ — нужно пять часов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от scor on 01-Ноя-09, 11:18
	>Процессор, память, диски? > >FreeBSD от нуля до "фильмец посмотреть" на Athlon X2 3800+/2ГБ — нужно >пять часов. Если не собирать KDE или GNOME, то пять часов многовато.:) Тормоза, скорее всего, из-за вывода на консоль. Попробуйте вывод компилятора в /dev/null отправлять, время компиляции на порядок сократится должно. Пот иксовым терминалом уже не так влияет, но тем не менее тоже заметно.:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от iZEN (ok) on 01-Ноя-09, 12:53
	>Если не собирать KDE или GNOME, то пять часов многовато.:) Система из сорцов (~ полтора часа для 64-битной), полное окружение Xfce 4.6 (~30 минут), библиотеки GNOME, Gedit, File-Roller, Nautilus и Gxine (здесь уж как получится). >Попробуйте вывод компилятора в /dev/null отправлять, время компиляции на порядок сократится должно. Это так что ли: cd /path/to/port/ && make install clean >> /dev/null ???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Оценка влияния флагов оптимизации GCC на производительность ..."		+4 +/–
	Сообщение от Michael Shigorin (ok) on 01-Ноя-09, 16:50
	>Это так что ли: >cd /path/to/port/ && make install clean >> /dev/null >??? Да, только обязательно ">>", чтоб не перетереть предыдущее содержимое /dev/null. Ещё вариант -- &>build.log, или 2>&1 | tee, или screen(1). -- ох уж эти шпециалисты
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	110. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от нечто on 02-Ноя-09, 07:51
	у make есть ключик такой, -s называется: "-s, --silent, --quiet Silent operation; do not print the commands as they are  executed." >[оверквотинг удален] >>Это так что ли: >>cd /path/to/port/ && make install clean >> /dev/null >>??? > >Да, только обязательно ">>", чтоб не перетереть предыдущее содержимое /dev/null. > >Ещё вариант -- &>build.log, или 2>&1 | tee, или screen(1). > >-- >ох уж эти шпециалисты
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	116. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 10:42
	>у make есть ключик такой, -s называется: К моему ответу ортогонально -- лог сборки-то как раз может быть полезен.  А вот к сообщению с предположением о торможении tty -- прямо относится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	135. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от iZEN (ok) on 02-Ноя-09, 14:54
	>>Это так что ли: >>cd /path/to/port/ && make install clean >> /dev/null >>??? > >Да, только обязательно ">>", чтоб не перетереть предыдущее содержимое /dev/null. > >Ещё вариант -- &>build.log, или 2>&1 | tee, или screen(1). > >-- >ох уж эти шпециалисты Давно уже использую алиас "make -s" для make, чтобы не засирать консоль. А в графическом терминале компиляция идёт на 10...20% медленнее, чем в текстовой консоли — возможно, задержка возникает из-за перерисовки букв средствами X.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	142. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от xaljava on 02-Ноя-09, 15:52
	>Да, только обязательно ">>", чтоб не перетереть предыдущее содержимое /dev/null. =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	115. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 10:40
	>Ну ты точно неадекват. +1, был стёрт за ругань и полную невменяемость.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от Sw00p aka Jerom on 01-Ноя-09, 10:10
	а вы знаете в чём отличие ынтерпрайза того самого микрософта и редхета ???? так вот поясню сам по себе ынтерпрайз редхет (которым сам лично пользуюсь) бесплатен а покупаете вы подписку на саппорт (довольно таки мощную) и стоимость дисков всего 20 баксов а если вам не хочется платить за подписку иди скачайте на сайте редхета ынтерпрайз и посмотрите
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 12:38
	Чушь это все :) Я уже писала выше, что не сказано вообще ничего про конкретику инсталляций Gentoo и Ubuntu, а последняя, в дефольтной инсталляции ставит, например, apparmor, который несколько снижает производительность. А еще, разные версии ядер (да и либ) Если же глянуть тесты на самом форониксе, то разные убунты и федоры между собой чаще еще больше отличаются. За тест автору незачет. Невоспроизводимый он.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от anonymous (??) on 01-Ноя-09, 15:05
	Мадмуазель, речь идет о конкретно взятом дистрибутиве Ubuntu 9.04 дефолтной установки и конкретно взятом Gentoo свежей сборки. Никого не волнует, включен там AppArmor или выключен, разные версии или одинаковые. Автор взял стандартные дистрибутивы, ничего не меняя, снял показания. То, что включен AppArrmor - это чья проблема, дистрибутводелателя или пользователя? Если снижает производительность, зачем он вам сдался включенным по умолчанию?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 17:04
	>Мадмуазель, речь идет о конкретно взятом дистрибутиве Ubuntu 9.04 дефолтной установки и >конкретно взятом Gentoo свежей сборки. Никого не волнует, включен там AppArmor >или выключен, разные версии или одинаковые. Автор взял стандартные дистрибутивы, ничего >не меняя, снял показания. >То, что включен AppArrmor - это чья проблема, дистрибутводелателя или пользователя? Если >снижает производительность, зачем он вам сдался включенным по умолчанию? Читаем: Gentoo Optimizations Benchmarked Gentoo is a source based distribution which lets the user decide how to optimize their system in many ways. Linux Magazine benchmarks three of the most common GCC optimizations; -Os, -O2 and -O3, and throws in Ubuntu for good measure. то есть, бубунта приведена в качестве "хорошего сравнения", по мнению авторов статьи, что не является правдой. Сравнение плохое, заведомо подложное. Почему, озвучено выше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	106. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от anonymous (??) on 02-Ноя-09, 01:27
	Однако это не отвечает на вопрос, почему дистроделы Ubuntu решили за пользователей то, что для них (пользователей) лучше или хуже. Ваш пример с AppArmor - яркое тому подтверждение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	118. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 10:45
	>Однако это не отвечает на вопрос, почему дистроделы Ubuntu решили за пользователей >то, что для них (пользователей) лучше или хуже. Ваш пример с >AppArmor - яркое тому подтверждение. И не должно -- это ж тест, а не анализ подхода различных дистрибутивов. Почему решили -- вполне понятно: для их аудитории заплатить немного производительностью за несколько дополнительных отловленных вовремя сегфолтов очень даже разумно.  Вот почему AppArmor, от которого отказался Novell (а Криспин ушёл в MS) -- пока непонятно, окромя как "шоб не по-редхатовски".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	112. "Оценка влияния флагов оптимизации GCC на производительность ..."		+3 +/–
	Сообщение от empty on 02-Ноя-09, 08:14
	>>бубунта приведена в качестве "хорошего сравнения" for good measure - это идиома. Читается "использовали генту с различными флагами оптимизации и вдобавок взяли убунту". Ошибки перевода - один из источников великих открытий ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	117. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 02-Ноя-09, 10:44
	>>>бубунта приведена в качестве "хорошего сравнения" > >for good measure - это идиома. Читается "использовали генту с различными флагами >оптимизации и вдобавок взяли убунту". > >Ошибки перевода - один из источников великих открытий ;) А тут (на этом форуме) развели флейм, что бинарные дистрибутивы тормозят, и вдобавок сделали  вывод, что тормозит бубунта. Я ей не пользуюсь, но, повторюсь, разница в производительности в некоторых тестах в тестах того же фороникса между разными версиями бубунты или той же федоры гораздо больше, чем в этих. Тест заведомо некорректен, в отношении Убунты, и только это я и хотела сказать. Вот в случае левых колонок (Gentoo, так как версии ПО совпадают) он корректен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от аноним on 01-Ноя-09, 18:09
	>Чушь это все :) Да безусловно чушь. У вас же есть более тщательное тестирование, где все разобрано по полочкам, и доказано, что форониксовская рисовалка графиков глючит и наоборот все рисует. Как дети, ей богу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	94. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 22:32
	>Да безусловно чушь. У вас же есть более тщательное тестирование, где все разобрано по >полочкам, и доказано, что форониксовская рисовалка графиков глючит и наоборот все рисует. >Как дети, ей богу. Нет, у меня нет бенчмарка. Но то, что в ссылке к новости, такого бенчмарка тоже лучше бы не было. Он неправильный, а неправильный бенчмарк хуже отсуствующего бенчмарка, так как вводит людей в заблуждение. И дело не в форониксовских графиках, повторюсь, а в исходной постановке задаче для тестирования: она неправильная и ангажированная.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	97. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от аноним on 01-Ноя-09, 23:24
	> Он неправильный, он не правильный, он не правильный ля-ля-ля, я вас не слышу, вас нет Бла-бла-бла. Давайте аргументы. По-моему правильней и показательней просто не придумать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	99. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 23:32
	>> Он неправильный, он не правильный, он не правильный ля-ля-ля, я вас не слышу, вас нет > >Бла-бла-бла. Давайте аргументы. По-моему правильней и показательней просто не придумать. Читайте выше. Я приводила аргументы :) Поиск по странице рулит :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Ноя-09, 16:26
	>Ну наконец-то то, о чем все вобщем-то всегда знали или предполагали, облекли >в удобную для восприятия форму. Разница местами в разы. Учитывая другие >проблемы бинарных пакетных систем (например, прибитые гвоздями зависимости и библиотеки - >а это на мой взгляд даже важнее производительности) Вы всерьёз полагаете, что у портообразных проблем нет?  Это что, медаль Мёбиуса? >уделом их остаются совсем слабые машины, а также жертвы FUD'а, которые считают >что собирать из исходников - это сложно или медленно. Жертвы FUD считают, что собирать из исходников -- это круто.  А нормальные люди понимают, что это бывает такая вынужденная необходимость по конкретным причинам. Мой домашний тазик описан здесь, например: http://freesource.info/wiki/MichaelShigorin/HomeBox -- его вполне хватает для сборки дистрибутивов (хотя на офисной сборочнице это и удобней, всё в памяти).  Не говоря о паре кластеров, к которым есть доступ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	87. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от аноним on 01-Ноя-09, 18:15
	>Вы всерьёз полагаете, что у портообразных проблем нет? Проблемы есть у всего, просто у бинарные их больше и они в принцыпе не решаемы из-за этой самой бинарности. >Жертвы FUD считают, что собирать из исходников -- это круто.  А >нормальные люди понимают Интересно, кому же надо было распространять FUD про исходники. >что это бывает такая вынужденная необходимость по конкретным причинам. Здорово же вы все с ног на голову перевернули. Вообще-то все наоборот - не собирать из исходников стоит только там где это слишком медленно. >Мой домашний тазик описан здесь, например: http://freesource.info/wiki/MichaelShigorin/HomeBox -- его вполне хватает для >сборки дистрибутивов (хотя на офисной сборочнице это и удобней, всё в >памяти).  Не говоря о паре кластеров, к которым есть доступ. Ну вот видите.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	120. "чем плохо компилить исходники без повода к тому"		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:06
	>>Вы всерьёз полагаете, что у портообразных проблем нет? >Проблемы есть у всего, просто у бинарные их больше "Больше" означает возможность сравнения.  Приведите свои списки или ссылки на них, мир ждёт. >и они в принцыпе не решаемы из-за этой самой бинарности. А проблемы портообразных (не говоря о диком самосборе с управлением одной только головой) -- в принципе не решаемы из-за этой самой портообразности.  Там выше (см. по слову "неадекват") очень внятно изложены несколько основных. >>Жертвы FUD считают, что собирать из исходников -- это круто.  А >>нормальные люди понимают >Интересно, кому же надо было распространять FUD про исходники. Тем, кому стыдно признаться, что смотреть на пролетающий по экрану хлам -- это не круто, а пустая трата времени.  Если гентушник собирает сильно кастомную систему, умело применяя возможности дистрибутива -- честь ему и хвала.  Если LFS-ник строит прошивку ровно так, как понимает её задачи -- аналогично.  Но если кто-то компилячит с утра до ночи вместо того, чтоб в магазин ходить -- то он красноглазая жертва наведённых fear некрутости, uncertainity в своих надобностях, и doubt в самом себе. Собсно я тут довольно много ругался на бздишников, что примерно таким же образом распространяют вирусное враньё про то, что "лялих суксь, фря рулез" при том, что подавляющее большинство аргументировать ничем не может, а кто может -- обычно помалкивают, потому как видят и там, и сям недостатки, умея и то, и сё. >>что это бывает такая вынужденная необходимость по конкретным причинам. >Здорово же вы все с ног на голову перевернули. А Вы на ноги встаньте да ещё раз гляньте. >Вообще-то все наоборот - не собирать из исходников стоит только там >где это слишком медленно. Не выпекать хлеб самому тоже стоит только там, где это слишком медленно?  А ничего, что даже при доступности компактных пекарен есть много факторов, из-за которых хлебушек одного хлебзавода покупаешь, а другого -- купишь раз, уж доешь и потом обходишь стороной? Поймите, я собираю -- оймама, уже под три сотни пакетов в ALT.  Рядом пересобирают для кластерных нужд подмножество альтовского репозитория.  _Это_ имеет смысл в рамках поставленных целей.  А вот пересобирать себе пакеты glibc да zlib с оптимизацией под процессор оставил давным-давно, хотя когда-то и это практиковал сдуру.  Не говоря про ядро (хотя для тонких клиентов -- пакетится отдельное). Как уже сказано -- возьмите арифметику да посчитайте, за какое время окупится сборка системы при разнице в 2--20% по производительности.  Это если брать время, когда тормозит система, а не человек.  Вот берём три часа компиляции, умножаем на 50..5 и думаем над полученной циферкой.  Желательно с учётом того, что цирк первым представлением не заканчивается. Поймите, я не против исходников, не против Gentoo или FreeBSD как таковых -- я против того, когда люди сами себя вводят в заблуждение и ещё и других пытаются.  У каждой вещи есть недостатки, просто их следует уяснять и не следует скрывать. >>Мой домашний тазик описан здесь, например: [...] -- его вполне хватает для >>сборки дистрибутивов (хотя на офисной сборочнице это и удобней, всё в >>памяти).  Не говоря о паре кластеров, к которым есть доступ. >Ну вот видите. Так я и вижу -- что везде на этих системах используются пакетные дистрибутивы, и на кластерах тоже движение от конструирования уникальных систем рашпилем и пинцетом к реюзабельным компонентным системам. Понимаете, дистрибутив, который я соберу за четверть часа из пакетов, которые до этого сутки молотились более мощным железом -- может быть полезен довольно многим людям.  А трата времени на уникальные системы, когда в них нет реальной надобности -- это отрывание времени от родных и близких с последующим его бесполезным прожиганием.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	139. "чем плохо компилить исходники без повода к тому"		+1 +/–
	Сообщение от Crazy Alex (??) on 02-Ноя-09, 15:28
	Сорри, не опнял только одного поинта: какое потерянное время? Компиляция - она ни походам в магазин, ни общению с родными и близкими не мешает никак. Ну и насчет "дикого самосбора с управлением одной только головой" - может, поясните? Зависимости в Генте вполне отслеживаются.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	145. "чем плохо компилить исходники без повода к тому"		–1 +/–
	Сообщение от pazke on 02-Ноя-09, 16:29
	> Ну и насчет "дикого самосбора с управлением одной только головой" - может, поясните? Зависимости в Генте вполне отслеживаются. Помимо зависимостей есть еще USE флаги и опции компилятора, в которые любой тру-генту-кулхакер обязательно лазит своими очумелыми ручками, с зачастую весьма нетривиальными проблемами в результате.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	149. "чем плохо компилить исходники без повода к тому"		+1 +/–
	Сообщение от anonymous (??) on 02-Ноя-09, 17:34
	чочочо? Труъ-гентушник ставит систему ОДИН раз. После этого система с базовыми USE, опциями компиляции и CFLAGS не трогается продолжительное время. Труъ-гентушник волен с системой делать что вздумается - допиливать оптимизацию можно в свободное время.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	151. "чем плохо компилить исходники без повода к тому"		–1 +/–
	Сообщение от empty on 02-Ноя-09, 18:04
	>>Труъ-гентушник волен с системой делать что вздумается Вот-вот, об чем и речь, в этом и состоит психология студента. Не студент уже должен понимать, что системой пользуется не только он один, и у него должна быть какая-то ответственность перед пользователями.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	161. "чем плохо компилить исходники без повода к тому"		–1 +/–
	Сообщение от Michael Shigorin (ok) on 03-Ноя-09, 00:05
	>Сорри, не опнял только одного поинта: какое потерянное время? Любая кастомизация стоит времени. Его потери можно анализировать -- например, одноразовые исходные потери нескольких часов..пары дней на сборку системы вместо установки за четверть..полчаса; многоразовые небольшие на подбор желаемого варианта использования имеющегося добра (а смысл брать с ручками и не крутить их -- с другой стороны, всё сразу не предопределишь, как именно хотелось); редкие заметные при столкновении с нетривиальными проблемами (раз в несколько лет у меня такое бывает и в процессе поддержки своих пакетов, когда степень предсказуемости остальной части системы всё-таки намного выше -- поскольку меньше вариативность). Вот у меня скоро запланирован апгрейд системы на очередной стабильный бранч, от чего ожидаются вполне конкретные улучшения вроде поддержки AMR в ffmpeg.  Цена этого -- от силы полчаса шуршания дисками на бэкап корня и dist-upgrade, далее с полдня на вылавливание очевидных плюх (система дома довольно старая и имеет право организовывать порой редкостные сочетания), далее несколько дней предсказуемого выгребания багрепортов от семьи и трансляции их в багзиллу и исправления, а далее всё как обычно за редкими исключениями при редких, опять же, обстоятельствах.  Данное действие никто особо не любит, но его последствия в большинстве случаев себя окупают. >Компиляция - она ни походам в магазин, ни общению с родными и близкими не >мешает никак. Помните? "...так, этот модуль подставляется... ой, Зина, не гони волну! ну вот, пока откомпиляется, пойду ещё пивка глотну" Уязвима не стадия "пока откомпиляется", а "так, этот модуль подставляется". :) >Ну и насчет "дикого самосбора с управлением одной только головой" - может, поясните? Надо было уточнить, наверное... это о слакваристах и подобных гордящихся отсутствием управления кодом в системе.  Бишь вообще клинике. >Зависимости в Генте вполне отслеживаются. Разумеется. PS: о времени: на понимание того, какие ручки куда зачем крутить, оно тоже нужно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
Сообщение от mike lee on 01-Ноя-09, 01:55
вобщем то достаточно бестолковое сравнение. x86_64 практически везде собран одинаково (ну конечно можно для более новых процов задействовать sse2,3,4 и прочии новые наборы команд, но это имхо большого рояля не сыграет). Нужно было брать x86 - там бы результат наверняка был бы интереснее - поскольку большинство дистрибутивов собирается под i686 (а то и 585). вообще дело ведь не только в флагах оптимизации, но и в опциях сборки - то бишь то во что транслируются USE флаги. по сути в Gentoo, при грамотной натройке юзов бинарник не содержит определенного количества ненужного для данной системы кода, что тоже может дать прироста производительности.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от AlexanderYt on 01-Ноя-09, 03:34
	> вообще дело ведь не только в флагах оптимизации, но и в опциях сборки - то бишь то во что транслируются USE флаги. по сути в Gentoo, при грамотной натройке юзов бинарник не содержит определенного количества ненужного для данной системы кода, что тоже может дать прироста производительности. Но хоть кто-то это отметил. А то опять пионеры затеяли срач ubuntu vs gentoo. Причем не только вопрос в производительности (не актуально), а способность отойти от зависимостей как в бинарных дистрах. Сам сразу же плюнул на оптимизацию и собираю все вообще с -O1 ибо быстро, а вот выбор функциональности с USE - это офигенная приятная плюха, хоть и требует  большого внимания.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Оценка влияния флагов оптимизации GCC на производительность ..."		–3 +/–
	Сообщение от pavel_simple (ok) on 01-Ноя-09, 03:41
	>способность отойти от зависимостей как в бинарных дистрах. в debian-based системах никогда с этим проблем не наблюдал. если у вас имеется конкретика - милости просим. Какие такие зависимости нельзя обойти в дистрибутивах основанных на пакетной системе?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от DFX on 01-Ноя-09, 06:28
	ну незнаю, дурачинка, как насчёт всех библиотек, которые можно подгружать не только по необходимости (аки -Wl,--as-needed), но и вообще выборочно выпилить при конфигурации сборки ? как же меня тошнит от "enterprise-админов" с удлинителем телесной сосны ввиде сотни помирающих серверов и плачущих бухгалтерш. проследуйте, пожалуйста, бздеть на курсы сертификации самых метанирующих специалистов всех областей IT в одном костном флаконе. PS: а тест очень странный. гибкость в настройке и развёртывании никак не показывает, а тесты производительности уже подустарели. нынче модно gcc 4.4.2 + graphite + оптимизация на уровне связывания[link] лично я предпочитаю на ноутбучке делать: GRAPHITE="-floop-interchange -floop-strip-mine -floop-block" CFLAGS="-march=k8-sse3 -Os -mfpmath=sse,387 -frename-registers -ftree-vectorize -finline-functions -findirect-inlining ${GRAPHITE} -Wno-error -pipe" CXXFLAGS="${CFLAGS} -finline-limit=1000 -fpermissive" LDFLAGS="-Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-O1" но я с ишибками памяти сам разобратся могу. мне непонятно почему тут кто-то сильно пукает по поводу что его заставят _поддерживать_ самосборные бинарники ? или у нас уже есть целые предприятия использующие gentoo на "серверах" без ECC, собирающие без проверки на качество с небезопасными флагами bleeding edge-софт единожды, орущие при первой же ошибке на поддержку, которая была настолько сурова и тупа что взялась это всё поддерживать ? покажите мне, страна должна знать своих кретинов!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 12:54
	>лично я предпочитаю на ноутбучке делать: >GRAPHITE="-floop-interchange -floop-strip-mine -floop-block" >CFLAGS="-march=k8-sse3 -Os -mfpmath=sse,387 -frename-registers -ftree-vectorize -finline-functions -findirect-inlining ${GRAPHITE} -Wno-error -pipe" >CXXFLAGS="${CFLAGS} -finline-limit=1000 -fpermissive" >LDFLAGS="-Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-O1" > >но я с ишибками памяти сам разобратся могу. мне непонятно почему тут >кто-то сильно пукает по поводу что его заставят _поддерживать_ самосборные бинарники >? Кроме ноутбука это больше негде делать :)? >или у нас уже есть целые предприятия использующие gentoo на "серверах" без >ECC, собирающие без проверки на качество с небезопасными флагами bleeding edge-софт >единожды, орущие при первой же ошибке на поддержку, которая была настолько >сурова и тупа что взялась это всё поддерживать ? >покажите мне, страна должна знать своих кретинов! Покажите лучше контору >100 серверов, где используется Gentoo :) страна должна знать своих героев :))) Если честно, я видела всего одну контору(из достаточно больших), использовавшую Gentoo на серверах... вместе с RHEL и Solaris,  и то только по тому, что за тот проект, где использовалась Gentoo, отвечал человек, страдающий (или наслаждающийся?) манией пересборки мира :) Так как человек был очень профессионален, и все у него, в общем-то, работало, в конторе на это закрывали глаза :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от аноним on 01-Ноя-09, 18:21
	Ну я знаю контору, там 300+ машин под генту. Если вы думаете, что они все что-то собирают, подумайте еще раз. Често говоря, устал спорить с людьми, у которых в мозгу до сих пор стойкая ассоциация gentoo=бесконечная сборка. Самим-то не смешно? Gentoo как минимум позволяет легко собрать и настроить болванку под любые нужны, протестировать и разложить. Установка на целевую машину будет быстрее чем ваши бесконечный "cборки" убунты, потому что код эффективней и размер меньше, по большей части из-за отсутствия ненужных депендов. Да и, кстати, возьмите любую контору, где используется FreeBSD. Сюрпрайз-сюрпрайз, там тоже все из исходников.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 20:46
	>Ну я знаю контору, там 300+ машин под генту. Если вы думаете, >что они все что-то собирают, подумайте еще раз. Често говоря, устал >спорить с людьми, у которых в мозгу до сих пор стойкая >ассоциация gentoo=бесконечная сборка. Самим-то не смешно? Gentoo как минимум позволяет легко >собрать и настроить болванку под любые нужны, протестировать и разложить. Установка >на целевую машину будет быстрее чем ваши бесконечный "cборки" убунты, потому >что код эффективней и размер меньше, по большей части из-за отсутствия >ненужных депендов. Нет, кажется, Вы не понимаете :) Gentoo и удобство массовой установки не очень совместимые понятия) Речь не об убунте, а, например, об RHEL/CentOS и Solaris :) погуглите по словам kikstart, jumpstart, PXE, Anaconda, Cobbler... И Вам станет стыдно, что Вы про какие-то болванки для сотен серверов говорите :) Сейчас все-таки XXI-ый век, и болванки больше интересны end-user'ам и копирастерам) >Да и, кстати, возьмите любую контору, где используется FreeBSD. Сюрпрайз-сюрпрайз, там тоже >все из исходников. У нас несколько тысяч серверов под FreeBSD. Мы ничего не компилим на боевых серверах :) Для этого есть специальные серверы, а ставим все либо с собственного зеркала, либо из своего репозитория, и автоматизированно. У нас свое, самописное решение, повторяющее, частично, функционал Anaconda для неинтерактивной PXE установки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	100. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от аноним on 01-Ноя-09, 23:32
	>Нет, кажется, Вы не понимаете :) Gentoo и удобство массовой установки не >очень совместимые понятия) Вот именно вы и не понимаете, видимо потому что не пробовали. Не пробовать простительно, а говорить про то, что не пробовали - непрофессионально. >погуглите по словам kikstart, jumpstart, PXE, Anaconda, Cobbler... Мда, свалить совершенно разные вещи в одну кучу... Что, по-вашему, gentoo и собранные под себя пакеты отменяют любую технологию массовой установки/развертывания? >И Вам станет стыдно, что Вы про какие-то болванки Да что с вами говорить... Под болванкой подразумевается образ для загрузки по сети.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	105. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от sHaggY_caT (ok) on 01-Ноя-09, 23:45
	>>Нет, кажется, Вы не понимаете :) Gentoo и удобство массовой установки не >>очень совместимые понятия) > >Вот именно вы и не понимаете, видимо потому что не пробовали. Не >пробовать простительно, а говорить про то, что не пробовали - непрофессионально. У Gentoo проблемы, в отличае от FreeBSD, со стабильностью портов. Во фре более адекватно подходят к поддержке старых систем. Gentoo, да, я ставила только "на посмотреть". Кстати, понравилось) Если бы у меня было больше времени (например, меньше сидела бы на этом форуме), возможно, она стояла бы на том  компьютере, с которого пишу эти строки(в Fedora слишком много, по-умолчанию, gtk-ых пакетов, а ставить кикстартом домашнюю систему, в котором запрещать левые пакеты, это уже перебор). Но вот на сервере... чур меня, чур! >>погуглите по словам kikstart, jumpstart, PXE, Anaconda, Cobbler... > >Мда, свалить совершенно разные вещи в одну кучу... Что, по-вашему, gentoo и >собранные под себя пакеты отменяют любую технологию массовой установки/развертывания? > >>И Вам станет стыдно, что Вы про какие-то болванки > >Да что с вами говорить... Под болванкой подразумевается образ для загрузки по >сети. Под Gentoo нет готового решения для развертывания сотен серверов :) Под FreeBSD тоже. Мы его сами для себя написали, так как достаточно много хороших девелоперов. Не все себе это могут позволить... Так вот, на мой взгляд, Gentoo это система для гиков(а вот FreeBSD промышленная, хотя лично мне во много раз больше нравится RHEL), но не для применения в production, а тема новости (оптимизации gcc) не очень стоят того внимания, которое ему уделяют гентушники. Видите ли, инструментов подобных Sattelite, Cobbler, Zenworks и пр. в системах наподобие Gentoo и Archlinux просто нет, их можно только сделать с нуля, а можно... не верить в какие-то там оптимизации формирования образов (которых там нет, в отличае от промышленных систем), а просто использовать то, что работает, и работает сразу. При этом я ни в коем случае не выступаю за то, что нужно использовать ПО как "черный ящик", наоборот, любая система должна быть открытой, понятной, и принцип kiss никто не отменял, менеджмент систем через тот же UNIX-way puppet гораздо удобнее, чем через Sattelite, просто... все должно быть в меру, в том числе красноглазие, и изобретение велосипедов для того, что уже было кем-то сделано, и работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	114. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от anonymous (??) on 02-Ноя-09, 09:48
	>У Gentoo проблемы, в отличае от FreeBSD, со стабильностью портов. Нефиг сидеть на антстейбле. > Во фре более адекватно подходят к поддержке старых систем. Угу. А еще адекватнее - во RHEL. Так адекватно, что они до сих пор на вусмерть бекпортированном 2.6.18 сидят. > Под Gentoo нет готового решения для развертывания сотен серверов Та-дам! http://wiki.github.com/funtoo/metro http://www.calculate-linux.ru/Calculate Нет или не искала? А может вообще не в теме???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	119. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от sHaggY_caT (ok) on 02-Ноя-09, 10:51
	>Угу. А еще адекватнее - во RHEL. Так адекватно, что они до >сих пор на вусмерть бекпортированном 2.6.18 сидят. Так это же хорошо :) ABI в версии сохраняется, железным вендорам удобнее писать драйвера под свои raid-массивы, контроллеры, и др. железки. >> Под Gentoo нет готового решения для развертывания сотен серверов > >Та-дам! http://wiki.github.com/funtoo/metro http://www.calculate-linux.ru/Calculate >Нет или не искала? А может вообще не в теме??? Про Calculate слышала, про metro нет. Все это детские игры, имхо. На сегодняшний день на x86/x86_64 платформе ведоры 3dparty приложений, и железные, поддерживают только RHEL, SLE, Solaris, Ubuntu. Ни Calculate, ни, к сожалению, Debian (а жаль, мне этот дистрибутив очень нравится, если бы не было RH, использовала бы его) для них не существует. Все остальное просто отсутствует в списках сертификации.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	134. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от anonymous (??) on 02-Ноя-09, 14:47
	>>Угу. А еще адекватнее - во RHEL. Так адекватно, что они до >>сих пор на вусмерть бекпортированном 2.6.18 сидят. > >Так это же хорошо :) ABI в версии сохраняется, железным вендорам удобнее >писать драйвера под свои raid-массивы, контроллеры, и др. железки. А потом при смене версии дистрибутива - хрясь! И мы больше не видим RAID, система накрывается медным тазиком! А бекапы на рейде! А дрова - только в новых ядрах! А новых ядер в новом дистрибутиве нет! Я конечно преувеличиваю, но бич бинарного дистрибутива - ты не обновишь его после прекращения срока поддержки. Он одним махом превращается в хлам. Бэкпортить - это великое зло драйверописателей. Вместо того, чтобы перепилить драйвера под новый ABI и получить от этого профит в виде свежих драйверов для свежего ядра, они зашориваются на конкретной версии, а потом хоба - и вдруг железки становятся нерабочими. Железным вендорам удобнее запихивать свои драйвера в ядро, чтобы вместо них в последствии работали люди Линуса.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	137. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от pavel_simple (ok) on 02-Ноя-09, 15:07
	>Я конечно преувеличиваю, но бич бинарного дистрибутива - ты не обновишь его >после прекращения срока поддержки. Он одним махом превращается в хлам. ну все вышесказанное уместно лишь в случае если upgrade провести ну ни как не получается - а это нужно придумать кучу доводов. обновление с Debian 3 на 4 прошул на ура С Debian 4 на 5 анологично. так зачем мне использовать неподдерживаемый дистрибутив если его можно проапгрейдить? P.S. постоянный bleeding edge в Debian тоже присутствует.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	143. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от sHaggY_caT (ok) on 02-Ноя-09, 15:58
	>А потом при смене версии дистрибутива - хрясь! И мы больше не >видим RAID, система накрывается медным тазиком! А бекапы на рейде! А >дрова - только в новых ядрах! А новых ядер в новом >дистрибутиве нет! Промышленные системы поддерживаются много-много лет:) только-только закончился период поддержки RHEL2, RHEL3 (а он на 2.4.x) еще будет поддерживаться (фиксы безопасности) еще долго :) В RHEL 4 до сих пор добавляют новые возможности, не только фиксят баги, RHEL 5 активно развивается, хотя ему не один год. Зачем обновлять систему, если она работает в каком-то проекте, выполняет свои задачи, и поддерживается вендором? Если инфраструктура проекта модифицируется, то ПО часто обновляется вместе с железом. Если железо остается старым, все равно никто на живую на боевых серверах ничего не обновляет(кроме критичных фиксов безопасности, применение которых, опять же, всегда тестируется), сперва все проверяют на стенде, когда процедура пройдет все согласования, когда будет понятно, что ничего не сломается, ноды проекта по очереди выводятся из ротации, и на них заливается система с нуля (естественно, предварительно сервисы с них перемещают на боевые серверы), либо реализуется еще какая похожая схема. А что касается поддержки оборудования... с чего бы для сервера, который по производительности еще не потерял актуальности, и находится в поддерживаемой линейке, производителю не выпустить сертифицированные драйвера для новой версии ОС? >Я конечно преувеличиваю, но бич бинарного дистрибутива - ты не обновишь его >после прекращения срока поддержки. Обновлять систему на боевом сервере, это мазохизм. Или садизм, по отношению к пользователям сервиса. На домашнем ПК? Там да, но мне лично и возможностей yum хватает) Успешно обновлялась FC6 >> F7 >> F8 >> F9. На последней мне не понравилась новая KDE, я поставила с нуля восьмерку, не так давно перешла на 11-ю федору, поставила с нуля. Тоже все работает. Хотя yum явно по-слабее по возможностям чем apt-get, если включить мозг, настроить приоритеты между репозиториями(а перед обновлением вообще удалить сторонние пакеты), то все Ваши ужастики будут ни о чем) Но мы говорили о промышленных системах)  Понимаете, любой баг должен быть, в большой сети, воспроизводим. Все серверы проекта должны быть на 100% идентичными (любой нестандарт на конкретной ноде должен быть документирован, а лучше что бы его не было). Так вот, в такой сети ужастики бинарных систем не актуальны:) >- это великое зло драйверописателей. Вместо того, чтобы перепилить драйвера под >новый ABI и получить от этого профит в виде свежих драйверов >для свежего ядра, они зашориваются на конкретной версии, а потом хоба >- и вдруг железки становятся нерабочими. Железным вендорам удобнее запихивать свои >драйвера в ядро, чтобы вместо них в последствии работали люди Линуса. Все они переписывают. По мере появления новых версий) Даже иногда отдают код под GPL в апстрим, если им надоедает хотя и изредка(ABI то ломается редко), но писать код под Enterpise системы. То есть, проблемы не существует.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	170. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Карбофос (ok) on 03-Ноя-09, 11:51
	с какой это радости? вы видимо не в курсе, что не в дистрибутив все упирается, а в апдейт кернела. а дистрибутив - это оболочка, может расширенная скриптами. если в производстве несколько критично, то делаются тесты на совместимость, все ли поддерживается. обычно модули дорабатываются, а не деактивируются
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	148. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от empty on 02-Ноя-09, 17:32
	>[оверквотинг удален] >писать драйвера под свои raid-массивы, контроллеры, и др. железки. > >>> Под Gentoo нет готового решения для развертывания сотен серверов >> >>Та-дам! http://wiki.github.com/funtoo/metro http://www.calculate-linux.ru/Calculate >>Нет или не искала? А может вообще не в теме??? > >Про Calculate слышала, про metro нет. Все это детские игры, имхо. На >сегодняшний день на x86/x86_64 платформе ведоры 3dparty приложений, и железные, поддерживают >только RHEL, SLE, Solaris, Ubuntu. Ни Calculate, ни, к сожалению, Debian Помните из старого совецкого фильма - "Чтобы быть женой генерала, нужно выйти замуж за лейтенанта" Советую взять на вооружение ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	122. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:17
	>http://www.calculate-linux.ru/Calculate >Нет или не искала? А может вообще не в теме??? Я с ними общался (попросили сделать зеркало на ftp.linux.kiev.ua) и осталось довольно странное впечатление: люди явно грамотные, но будто варящиеся в своём соку скорее изолированно. И прекратите на девушку с кулачками подпрыгивать, она явно знает больше страшных слов. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	127. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от anonymous (??) on 02-Ноя-09, 11:33
	>>http://www.calculate-linux.ru/Calculate >>Нет или не искала? А может вообще не в теме??? > >Я с ними общался (попросили сделать зеркало на ftp.linux.kiev.ua) и осталось довольно >странное впечатление: люди явно грамотные, но будто варящиеся в своём соку >скорее изолированно. Calculate, в общем-то, самобытный дистрибутив и очень молодой. И они действительно изолированы, так как нет сформировавшегося сообщества и он ориентирован на русскоговорящих пользователей (для развития дистрибутива - это минус). Однако их идеи - сеты установки, допил обновлений, CLS - очень и очень перспективны для Gentoo. >И прекратите на девушку с кулачками подпрыгивать, она явно знает больше страшных >слов. :) А я знаю больше добрых, ласковых и теплых :)).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	184. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от DFX on 04-Ноя-09, 04:40
	Нет, кажется Вы не понимаете. Погуглите по словам build-server, gentoo packages, getdelta, [g]PXE. Что же вы таки лукавите ? сами же прекрасно знаете как можно развернуть gentoo и все обновления на любое количество машин с одной материнской, при этом подстроив эту сборку под любые нужды. И даже признаётесь. И про BSD и про методы развёртывания. стыдно И кто там начал мерятся серверами, а ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	186. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 04-Ноя-09, 10:25
	>Нет, кажется Вы не понимаете. Возможно, я чего-то и не понимаю) Как Вы успели заметить, бинарный Линукс (а именно RHEL/CentOS) мне ближе, чем FreeBSD и Gentoo. И у нас мне гораздо больше интересна та же PVC, чем сборка пакетов из портов под FreeBSD, или сервисы, отвязанные от специфики ОС. У нас я вижу функционал, который, во многом, копирует то, что есть в RHEL/SLE платформе, конечно, адптированно под специфику нашей сети. Уверены ли Вы, что адекватно представляете преимущества и недостатки Enterprise систем? Мне почему-то кажется, что нет. >Погуглите по словам build-server, gentoo packages, getdelta, [g]PXE. >Что же вы таки лукавите ? сами же прекрасно знаете как можно >развернуть gentoo и все обновления на любое количество машин с одной >материнской, при этом подстроив эту сборку под любые нужды. Если нельзя, но очень хочется, то можно (с) >build-server В инфраструктуре на rpm/dpkg based системах это не нужно(под едичиный шаблон сервера нормально собрать две-три rpm-ки руками, rpmbuild'ом, без всякой автоматизации), но и тут тоже, если нельзя, но очень хочется, то можно: BuildService, rpath >getdelta зачем это? Есть в природе такой delta-rpm, и если да, для домашних пользователей с dial-up и GPRS это актуально, для Enterprise.. Может, кому и нужно, конечно, анлимы не у всех предприятий, но какая-то локальная (имхо) фича >И даже признаётесь. И про BSD и про методы развёртывания. стыдно Если Вы внимательно прочитаете, что я писала в этом сообщении и раньше, то увидите, что я сказала про дописанный нами отсуствующий функционал. Вы сами-то видели, что может та же Anaconda, сколько в ней кода(и кода совсем не пустого, а что-то реализующего), синтаксис kikstart'ов? Если мало возможностей синтаксиса Kikstart'ов, есть Cobbler с его сниппетами. Кстати, что Вы будете использовать для маштабного мониторинга уязвимых версий ПО на > 1k систем? Под RH есть Sattelite и бесплатный Spacewalk, и они работают... И работают давно... А у Вас... тут один патч, тут собрано с одними use= а тут, с другими... Зачем, если можно проще и понятнее? Отмечу, что наличие какой-то кривой зависимости(тянущей всякий мусор) в сборке вендором бинарного дистрибутива не помешает пересобрать один (или несколько) пакетов, и положить их в свой кастомный репозиторий. Имхо, их поддержка будет гораздо проще, чем поддержка недокументированных фич в разных шаблонах серверов. А так же, с отсуствием сертификации? Нет никаких гарантий того, что какой-нибудь FBA адаптер всегда заведется в Вашей обновленной Gentoo, так как производитель адаптера Генту не замечает как явление... У нас с такими проблемами достаточно часто сталкиваются под FreeBSD. В RHEL и SLE, с их стабильным ABI, и сертификацией производителем, это не возможно, и просто нет необходимости даже в том же аналоге module assistent из Debian, так как все и так работает :) >И кто там начал мерятся серверами, а ? Я ничем не мерилась, так как моя должность не подразумевает принятия решений по развитию инфраструктуры, я просто работаю в этой компании почти два года, хотя есть планы по созданию с любимым человеком своего бизнеса :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	183. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от DFX on 04-Ноя-09, 04:29
	а что вы таки имете против моего ноутбука ? у него ещё есть 3 друга, которые ему помогают, но к делу это не относится. >Покажите лучше контору >100 серверов, где используется Gentoo :) показываю: http://www.gentoo.org/main/en/sponsors.xml -> http://www.gentoo.org/news/en/gmn/20080424-newsletter.xml#do... "All in all with all hosts accounted for we have 1800 servers most of them with 2 or 4 cores each. All of these run Gentoo Linux. :-)" в нашей стране не покажу, к сожалению, засилье братского и ненавистного BSD не даёт. ещё не могу понять отчего Альтовцы, тут высказывающиеся, так убеждены что "этой вашей уникальноый системой" "будут пользоваться другие люди". какие такие другие люди будут пользоваться системой с моих ящиков ? "aaaAAA! i've been invaded !"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	187. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 04-Ноя-09, 10:31
	>в нашей стране не покажу, к сожалению, засилье братского и ненавистного BSD >не даёт. У хостера 1Gb Linux'овые серверы на Gentoo. Сколько у них серверов, не знаю, но судя по рейтингу на 1stat.ru, с проблемами управляемости инфраструктуры они должны были столкнуться. У них же есть Apache в production на Windows. Хочется повторить ту же фразу про "если нельзя, но хочется" :))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	188. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 04-Ноя-09, 11:29
	>а что вы таки имете против моего ноутбука ? Ничего, окромя того, что localhost -- это очень узкий взгляд почти на любые вещи. >у него ещё есть 3 друга, которые ему помогают, но к делу >это не относится. У меня только в этой комнате пять хостов, не считая точки. :)  И не говоря о серверах и контейнерах.  Самый старенький бук, которому пора на пенсию, представлял бы заметные проблемы по локальной сборке, а тонкий клиент в любом случае администрируется в BIOS (и в рамках терминального сервера). Да, моя голова была бы и хранением деталей конфигурации этих машинок уже слишком пригружена.  Семи пядей во лбу не наблюдается, а на свободные и так много желающих. >ещё не могу понять отчего Альтовцы, тут высказывающиеся Пока _тут_ таких высказавшихся наблюдаю одну штуку в своём лице. >так убеждены что "этой вашей уникальноый системой" "будут пользоваться другие люди". Как раз наоборот: такое ощущение, что Вы тратите уйму времени на окучивание аж самого себя.  Вспоминают же людей, которые при жизни успели сделать многое для _других_.  Разумеется, дело сугубо личное, но раз уж непонятно... >какие такие другие люди будут пользоваться системой с моих ящиков ? С таким подходом -- надеюсь, никакие.  Но более надеюсь, что поймёте и _суть_ высказанного -- собсно никакой дистрибутив сам по себе не помеха делать людям добро, просто на это уходит разное количество времени и сил. А себе любимому... простите, но это-то к какому делу относится?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от anonymous (??) on 01-Ноя-09, 17:26
	>покажите мне, страна должна знать своих кретинов! Зеркальная генту болезнь ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	121. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:12
	>ну незнаю, дурачинка, как насчёт всех библиотек, которые можно подгружать не только >по необходимости (аки -Wl,--as-needed) Прекратите ругаться на собеседника и марш читать, чем на самом деле занимается --as-needed (hint: на стадии линковки, о чём говорит и -Wl, а не в рантайме). >но и вообще выборочно выпилить при конфигурации сборки ? В альте многие пакеты обвешены несколькими, а то и кучей, %def_with/without -- и можно собрать нужное путём rpmbuild -ba --with фича.  USE-флаги отличаются от этого добавлением унифицированного пространства имён и инфраструктуры его использования, но технически ничто не мешает сделать то же самое для пакетных дистрибутивов (по крайней мере некоторых).  Видимо, просто нужда преувеличена -- а у кого она реальная, для тех уже есть генту. >мне непонятно почему тут кто-то сильно [...] по поводу что его заставят _поддерживать_ >самосборные бинарники? Очевидно, Вы никогда не приносили пользы другим людям (а вместе с ней и непредвиденных проблем, которые приходилось решать постфактум) >покажите мне, страна должна знать своих кретинов! Давайте оставим процитированное здесь сообщение, пусть знает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от КдешнегГентушнег on 01-Ноя-09, 12:29
	А ну попробуй из debian-based сделать систему для настольной работы с рабочим столом KDE вообще без Gtk-шных зависимостей. Слабо?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Alexey (??) on 01-Ноя-09, 12:39
	А я думал компьютер нужен для того, чтобы на нем работать, а не чтобы реализовывать свои эротические фантазии. Пока жители Вилларибы компилят Генту, жители Вилабаджо уже давно установили Убунту (Дебиан, Ред Хат, ...) и зашибают на нем деньги.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	162. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от pavlinux (ok) on 03-Ноя-09, 03:58
	>А ну попробуй из debian-based сделать систему для настольной работы с рабочим >столом KDE вообще без Gtk-шных зависимостей. Слабо? нукась, ldd `which konqueror`
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	175. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от anonymous (??) on 03-Ноя-09, 15:53
	$ ldd 'which konqueror' ldd: ./which konqueror: Нет такого файла или каталога уппсс...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	180. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 03-Ноя-09, 17:32
	>$ ldd 'which konqueror' >ldd: ./which konqueror: Нет такого файла или каталога Копипастом надо было или присмотреться -- pavlinux написал бэктики (backticks, обратные одинарные кавычки -- живут вместе с тильдой), а Вы взяли апостроф и вместо результата работы команды which konqueror подставили строчку из двух слов и пробела между ними.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	182. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от pavlinux (ok) on 03-Ноя-09, 19:03
	>$ ldd 'which konqueror' >ldd: ./which konqueror: Нет такого файла или каталога > >уппсс... ldd $(which konqueror) | grep lib[g] Какой же такой сИкретный браузер у Вас под KDE, без Glib зависомостей.???
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	189. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 04-Ноя-09, 12:04
	>ldd $(which konqueror) | grep lib[g] >Какой же такой сИкретный браузер у Вас под KDE, без Glib зависомостей.??? Хех.  Ну стоит тут рядом такой: pad:~> ldd $(which konqueror) | grep libg           libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f25000) pad:~> ldd `which konqueror` | wc -l     44 pad:~> rpm -qf =konqueror                 kdebase-konqueror-3.5.10-alt14 Но у нас всё по умолчанию с --as-needed собирается ;-) (начали в 2006; справедливости ради, через некоторое время заметил то же веяние и конкретно в Gentoo)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от AlexanderYT on 01-Ноя-09, 15:54
	> если у вас имеется конкретика - милости просим. Какие такие зависимости нельзя обойти в дистрибутивах основанных на пакетной системе? 1. Бэкпорт ряда тяжеловесных приложений в стабильный резиз Debian. Извольте сделать это с минимальным коэффициентом (в сравнении с генту), равным гемор*время.     2. Установка разных версий одного и того же приложения. Ну, это на вскидку.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	98. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от khz on 01-Ноя-09, 23:26
	>> если у вас имеется конкретика - милости просим. Какие такие зависимости нельзя обойти в дистрибутивах основанных на пакетной системе? > >1. Бэкпорт ряда тяжеловесных приложений в стабильный резиз Debian. Извольте сделать это >с минимальным коэффициентом (в сравнении с генту), равным гемор*время. >2. Установка разных версий одного и того же приложения. >Ну, это на вскидку. 1) ололо! backports.org 2) А зачем? Хоть один реальный пример? Очередной вброс воинствующего гентушнега?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	103. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
	Сообщение от аноним on 01-Ноя-09, 23:36
	>1) ололо! backports.org Ололо, а теперь попробуйте оттуда поставить что-то, что требует новой версии уже установленной библиотеки. А потому все это еще и обновить. Вот тут ололо и начнется. >2) А зачем? Хоть один реальный пример? Разные PHP и перлы на хостинге. Мало? Несколько версий библиотеки для тестирования совместимости с ней своей программы. Установка в ~ или временную директорию.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	123. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:22
	>>2) А зачем? Хоть один реальный пример? >Разные PHP и перлы на хостинге. Мало? Контейнеры.  Вообще-то на хостинге они как бы обязательны, даже для dedicated -- чтоб не отдавать всю систему сразу при проломе чужого кода, который весь никак не проаудитишь.  Так что не то что мало, а пример против Вас работает. >Несколько версий библиотеки для тестирования совместимости с ней своей программы. >Установка в ~ или временную директорию. Чруты, контейнеры, виртуалки, сборка влево.  В альте можно удобно сделать нужное изолированное окружение при помощи hasher и в ём же и запустить свою софтинку (hsh-run).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	133. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от anonymous (??) on 02-Ноя-09, 14:37
	И кто это потом поддерживать будет? А если в пределах контейнера нужно несколько версий php? python? ruby? gcc? Их тоже по контейнерам разносить? Чруты любой накидать сможет, а обновлять кто будет? Это ваше изолированное окружение - как его поддерживать в актуальном состоянии?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	138. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от pazke on 02-Ноя-09, 15:15
	> И кто это потом поддерживать будет? А генту у вас таинством небесным сама собой поддерживается ? > Чруты любой накидать сможет, а обновлять кто будет? Это ваше изолированное окружение - как его поддерживать в актуальном состоянии? chroot /jail apt-get upgrade замечательно работает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	177. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от sHaggY_caT (ok) on 03-Ноя-09, 17:19
	>Чруты любой накидать сможет, а обновлять кто будет? Это ваше изолированное окружение - >как его поддерживать в актуальном состоянии? Puppet, в его сегодняшнем виде, способен сэкономить время системного администратора, и позволить одному человеку поддерживать сотни хостов(физических и виртуальных) в актуальном и допиленном состоянии ) Это гораздо проще, чем допиливать годами одну инсталяцию генты с кучей разных флагов и пр. мурости, в которой потом сто раз запутаешься. Есть и другие решения, помимо паппета, тот же Sattelite, например) Он, конечно, не очень UNIX-way, но позволяет, через SQL-запрос, представить в удобоваримом виде, какие пакеты стоят в каких системах, даже если хостов десятки тысяч) Такой же удобный централизованный менеджмент всех этих тысяч хостов (пересетапы, развертывание по PXE, обновление дырявых пакетов после появляения пакета с фиксами(или его самостоятельной сборки))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	185. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от DFX on 04-Ноя-09, 09:29
	А что, в Gentoo Puppet уже перестал работать ? или может быть поддержку генты оттуда куда то спрятали ? http://log.onthebrink.de/2008/05/using-puppet-on-gentoo.html я смотрю, вас, бедненьких, прямо самолично заставляют поддерживать тысячи установок генты в каждом датацентре и доме страны и обязательно децетрализованно. дело про убунту, а мы про сервера и какой у нас толстый "энтерпрайз". и хоть бы веть один генту вживую видел - нет. будем много говорить о том как мы не хотим и "оно сложна и нипанатнааа"(c). ядро, собраное в генте _своими_ руками тоже упорно не грузится по PXE ? как же такое ядро прошло QA-тестирование до ваших кластеров ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	190. "цена рекомендации"		+/–
	Сообщение от Michael Shigorin (ok) on 04-Ноя-09, 12:08
	>я смотрю, вас, бедненьких, прямо самолично заставляют поддерживать Да не в том дело, что "заставляют".  А в том, что отдельно взятая молодёжь, размахивая шашкой, не соразмеряет пользы и вреда. В своё время дошло, что рекомендуя что-либо людям -- будь готов _сам_ поддержать советом.  Не сослаться на "сообщество", а _сам_ потратить время на вот этого человека.  Знаете, очень хорошо вправляет мозги по части времяёмких рекомендаций. (причём для некоторых применений я бы порекомендовал посмотреть как раз на LFS/Gentoo, а не на пакетные дистрибутивы -- при наличии оснований полагать, что там времени больше сожрут последние) Понимаете, одно дело говорить "у меня всё работает" (в уме -- на локалхосте).  А другое, когда кто-нить из начинающих админов, на которых начальство свалило задачу "к понедельнику шоб был сервер" -- поверит кому попало и угробит время сперва чтоб получить втык и ещё неделю времени, а затем и ещё несколько лет до осознания того, что вообще-то тот кто-то на форуме был неправ применительно к данной ситуации. >как же такое ядро прошло QA-тестирование до ваших кластеров ? Ядра Gentoo не проходили QA "до наших кластеров".  Вообще ещё на кластерах оного видать не доводилось. PS: да видел я вашу генту, видел.  И слакварь видел.  Не волнуйтесь так.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	193. "цена рекомендации"		+/–
	Сообщение от AlexanderYT on 04-Ноя-09, 21:59
	>Понимаете, одно дело говорить "у меня всё работает" (в уме -- на >локалхосте).  А другое, когда кто-нить из начинающих админов, на которых >начальство свалило задачу "к понедельнику шоб был сервер" -- поверит кому >попало и угробит время сперва чтоб получить втык и ещё неделю >времени, а затем и ещё несколько лет до осознания того, что >вообще-то тот кто-то на форуме был неправ применительно к данной ситуации. > Сие понятно. Но вернемся что ли к десктопам. В начале этого года или в конце прошлого в пакетные дистрибутивы начали активно пихать пульз, особо в те, которые курируются "корпорациями". Сейчас моду  на пульз подхватили и догоняющие. Вы наверное видели, сколько людей про пульс говорят "лестных" слов?  Так вот статистика моя скромная говорит от том, что время, потраченное на выковыривание пульза из дистрибутивов на которых я сидел (а надо было, ибо без звука на десктопе скучновато) в  сумме больше, чем я потратил на первую тестовую установку десктопа на Gentoo, а потом уже на повторную и окончательную (и конечноже с USE=-pulseaudio). А может вы еще сталкивались с пакетами в стабильном дистрибутиве, которые имеют версию 1.2 например, и данная версия имеет багу, которая именно вам мешает нормально с ней работать. И что мы видим? Оказывается, сия бага исправлена в версии 1.3, но в этот монолитный пакетный дистрибутив эта версия попадет только в случае с бэкпортом (либо слезно просить мантейнера, что бы он пофиксил текущую версию). А сколько времени надо на бэкпорт приложения, который глубоко интегрирован в систему? Через пару суток вы поймете, что ваша система превратилась в адский микс stable и testing, а результат не достигнут.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	194. "обновление софтового стека"		+/–
	Сообщение от Michael Shigorin (ok) on 15-Ноя-09, 23:55
	>Вы наверное видели, сколько людей про пульс говорят "лестных" слов? http://lists.altlinux.org/pipermail/sisyphus/2009-September/... >Так вот статистика моя скромная говорит от том, что время, потраченное >на выковыривание пульза из дистрибутивов на которых я сидел (а надо было, >ибо без звука на десктопе скучновато) в  сумме больше, чем я потратил на >первую тестовую установку десктопа на Gentoo, а потом уже на повторную >и окончательную (и конечноже с USE=-pulseaudio). Верю, но по крайней мере сейчас в альте это одна команда. >А может вы еще сталкивались с пакетами в стабильном дистрибутиве, которые имеют >версию 1.2 например, и данная версия имеет багу, которая именно вам >мешает нормально с ней работать. И что мы видим? Оказывается, сия >бага исправлена в версии 1.3, но в этот монолитный пакетный дистрибутив >эта версия попадет только в случае с бэкпортом (либо слезно просить >мантейнера, что бы он пофиксил текущую версию). А сколько времени надо >на бэкпорт приложения, который глубоко интегрирован в систему? Смотря насколько.  Клинические случаи обычно представляют собой переезд сразу стека (обычно мультимедийного), и там что для пакетного дистрибутива это скорее всего означает переезд между бранчами -- когда очередная фаза бэкпорта упирается уже в тулчейн, что для source-based в эквивалентные изменения с пересборкой всего зависимого от многого уехавшего. >Через пару суток вы поймете, что ваша система превратилась в адский микс stable >и testing, а результат не достигнут. Можно через пару часов понять, что хватит бэкпортить и пора dist-upgrade.  Судя по своей практике -- результат достигается намного быстрее, чем пересобралось бы хотя бы полсистемы. Собственно, сейчас на домашнем десктопе как раз добрался переехать с альтовского 5.0/branch на 5.1/branch -- посмотрим, что будет.  Из неприятного -- сперва пришлось немного tetex откоцать руками, apt терялся на переезде с tetex на texlive, когда ещё не все зависимые пакеты переехали (пишу по ходу отчёт в community@, вдруг самому же и пригодится потом).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	107. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от AlexanderYT on 02-Ноя-09, 01:58
	В принципе вам уде ответили, но тем не менее >1) ололо! backports.org Там далеко не все что может потребоваться, так что не 100% панацея. >2) А зачем? Хоть один реальный пример? Опять же вам ответили, но добавлю еще: установка необходимого пакета, который требует python древней верии (вот такие капризы у разрабов в 21 веке) >Очередной вброс воинствующего гентушнега? Нет. Сидел на дебе 2 года и снего в принципе начинал, дистр весьма крут, но различия пакетных дистров и gentoo слепому должны быть видны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от fooser on 01-Ноя-09, 08:30
	>[оверквотинг удален] >можно для более новых процов задействовать sse2,3,4 и прочии новые наборы >команд, но это имхо большого рояля не сыграет). Нужно было брать >x86 - там бы результат наверняка был бы интереснее - поскольку >большинство дистрибутивов собирается под i686 (а то и 585). > >вообще дело ведь не только в флагах оптимизации, но и в опциях >сборки - то бишь то во что транслируются USE флаги. по >сути в Gentoo, при грамотной натройке юзов бинарник не содержит определенного >количества ненужного для данной системы кода, что тоже может дать прироста >производительности. 585? лолштооо?)) народ, вот и вскрылся реальный уровень квалификации гентушника :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от Гений (ok) on 01-Ноя-09, 12:37
	>585? лолштооо?)) народ, вот и вскрылся реальный уровень квалификации гентушника :) в смысле что они тоже умеют опечатываться? ужас-ужас
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	124. ":]"		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:24
	>>585? лолштооо?)) народ, вот и вскрылся реальный уровень квалификации гентушника :) >в смысле что они тоже умеют опечатываться? ужас-ужас Я понимаю -- опечататься "1024" вместо "1000", но уж 586-то должно с трёх пальцев быстрее скатываться, чем с двух -- 585. (страшная догадка: или они одним набирают?)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	144. ":]"		+/–
	Сообщение от Xaionaro (ok) on 02-Ноя-09, 16:09
	Человек мог набрать сначала к примеру "385" (опечатавшись вместе "386"), а потом решить заменить "386" на "586" и получить "585". И множество других примеров. У меня большенство самых странных опечаток появляются именно во время исправлений. Я дак лично вообще не мог понять в чём описка ибо вообще не замечал "5"-ки на конце, и уже хотел начать писать пост с вопросом, мол "а что тут не так то собственно?". Только уже когда начал писать пост, заметил о чём речь :) Вообщем, аргумент крайне не убедителен.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "Оценка влияния флагов оптимизации GCC на производительность "		+2 +/–
Сообщение от empty on 01-Ноя-09, 10:59
Ага, только пользователи генты такие умные, что знают про флаги -O..., а в бинарных дистрибутивах сборщики или по своей глупости, или вредности, или религиозным принципам флаг -O2 никогда не используют ;) Оптимизация достигаемая в генту по сравнению с бинарными дистрибутивами может быть достигнута только за счет -mtune=, но, к сожалению для гентушников, тут фиг нормальый бенчмарк придумаешь, а во вторых и оптимизация за счет различных -mtune не настолько критична. Причем сами разработчики программы должны предположить возможность такой оптимизации и добавить соответствующие куски кода. Единственный пример где можно получить тут более менее большой выигрыш - это ATLAS (оптимизированный LAPACK). Но это настолько специальный случай, в лучшем случае 1% гентушиков им воспользуется. Но никто не мешает и в бинарных дистрибутивах пересобрать такие вот специальные пакеты.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

57. "Оценка влияния флагов оптимизации GCC на производительность ..."		+2 +/–
Сообщение от qwerty (??) on 01-Ноя-09, 12:48
Авторы членомерки — достойные ученики форониксов. Как можно приписывать флагам gcc то, что в "некоторых режимах GtkPerf и Qgears Ubuntu показал более высокую производительность", если в их Дженте используется тормозной XServer 1.5.3, а в Убунте 1.6? (Да и видяхи у них разные) Я сам как-то давно гонял GtkPerf на 1.4.2 им 1.5.1, последний сливал по-дикому. Конкретных значений не помню, на форуме фороникса мне рекомендовали перейти на git 1.6 или хотя бы 1.5.3. У 1.6 не было даже пререлизов, поэтому ставил 1.5.3 — прирост был, но до 1.4.2 всё равно не дотягивал. Потом появился rc1 1.6 — только с ним вернулась скорость 1.4.2.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от аноним on 01-Ноя-09, 18:26
	>Как можно приписывать флагам gcc то, что в "некоторых режимах GtkPerf и > Qgears Ubuntu показал более высокую производительность" Да будет вам известно, эффективность кода влияет не только на throughput, но и на latency. Посему коду не обязательно грузить процессор на 100% чтобы быть заметно быстрее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

62. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
Сообщение от DIO on 01-Ноя-09, 13:25
мда... не много сказано толкового и по существу... можете много мерятся различными органиами, их длиной и толщиной. мое общение с убунтоводами достаточно печально, причин много: - мозг отсутствует, действуют по принципу всовывания диска в сидивод и выбора скина инсталятора, т.е. вин-вей - понимание структуры системы, понимания идеологии никса - "0" - желания разобратся в чем либо - нет. - при поломке системы , переразбивается винт и накатывается новая система, при этом некотрые не знают даже какая ФС у них на винте. (хочу посмотреть на сию процедуру на сервере "вчера работавшем") "полное падение нравов" (с) постор Шлаг гента имеет плюс хотя бы в том, что она заставляет подумать. не хочу развивать флейм дальше скажу что важна не ОС а те руки которые к ней допущены. можно дятлу датьнапример солярку и он с ней ничег не сделает, а можно толковому человеку дать винду и он допилит систему до нормальности, однако зачем мучать себя например той же виндой... з.ы. не для флейма: господа убунтологи - у меня есть не одна ситуация когда я заставлял человека поставить генту , довести до рабочег состояния а потом предлагал снести и ставить что хочешь. так вот после этого процеса ни у одного з оных невозникло проблем нис сусей ни с фрей нис центосом... попробуйте так же сделать с бубном. з.ы.ы. ничего личного.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от AlexanderYt on 01-Ноя-09, 13:47
	> гента имеет плюс хотя бы в том, что она заставляет подумать. Запарил этот дебильный довод. Гента заставляет, убунту не заставляет. Инвалидность какая-то. Зачем себя ЗАСТАВЛЯТЬ думать , не понимаю. Поверь, в убунту можно думать не хуже чем в генту, если ЗАХОТЕТЬ.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	130. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от tux2002 (ok) on 02-Ноя-09, 13:37
	Кроме думать надо ещё и понимать. А понимать можно то, что способна вместить черепная коробка. Поэтому Slackware :)))))) шютка
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	155. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от User294 (ok) on 02-Ноя-09, 18:57
	>Кроме думать надо ещё и понимать. А понимать можно то, что способна >вместить черепная коробка. При том половина гентушников не отличается глубокими познаниями в работе любимой операционки. Зато пальцы - веером :). Source Based! \m/ \m/. Так, всего лишь наблюдение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	168. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от anonymous (??) on 03-Ноя-09, 08:32
	По сравнению с Убунтой половина - это не так уж и плохо. Всяко лучше, чем 95 %. Так, всего лишь личный опыт.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от mike lee on 01-Ноя-09, 14:42
	> гента имеет плюс хотя бы в том, что она заставляет подумать. я вообще полагал что у ОС несколько иная задача, чем заставлять пользователя думать. имхо как раз наоборот, должно быть удобно, а не чтоб думать. мне гента как раз нравится логичностью, и единообразием.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Anhel on 01-Ноя-09, 15:22
	а это как раз самая большая проблема линукса на десктопе вообще - он заставляет пользователя думать над ОС, вместо того чтобы думать над своей прикладной задачей в этой ОС, и пока Убунта пытается эту ситуацию исправить, Генту этим гордится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от mma on 01-Ноя-09, 15:57
	Ну а чем принципиально тогда lindows(ubuntu) лучше windows -  и там и там за вас подумали, работайте наздоровье. Все дело в том что на сегодня осталось всего два  самостоятельных comunity-дистрибутива которые можно таковыми назвать в полной мере это  debian  и gentoo, и их надо ценить а не пинать по каждому поводу. ubuntu, fedora, opensuse, mandriva - тут балом правят большие босы, за что они платят то и делают разрабы. Перестанут платить, например марк забросит убунту, и все фактически смерть - пока там наберется рабочее комьюнити(если наберется вообще), пока найдут финансирование  core-team (тех кому нужны результаты работы не вразрез комьюнити)...........
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	101. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от khz on 01-Ноя-09, 23:33
	>[оверквотинг удален] >Все дело в том что на сегодня осталось всего два  самостоятельных >comunity-дистрибутива которые можно таковыми назвать в полной мере это  debian > и gentoo, и их надо ценить а не пинать по >каждому поводу. > >ubuntu, fedora, opensuse, mandriva - тут балом правят большие босы, за что >они платят то и делают разрабы. Перестанут платить, например марк забросит >убунту, и все фактически смерть - пока там наберется рабочее комьюнити(если >наберется вообще), пока найдут финансирование  core-team (тех кому нужны результаты >работы не вразрез комьюнити)........... Пользователи centos, archlinux и altlinux яростно негодуют.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	109. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от mma on 02-Ноя-09, 07:50
	centos -  ну вообще смешно, хороший дистр - но перекомпиляция rhel  это не есть самостоятельный проект,  altlinux -  сейчас никакпли не комьюнити проект(покарйней мере пока), archlinux - каюсь, упустил, развивается проект
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	126. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:32
	>centos -  ну вообще смешно, хороший дистр - но перекомпиляция rhel > это не есть самостоятельный проект Угу. >altlinux -  сейчас никакпли не комьюнити проект(покарйней мере пока) Не "комьюнити" в плане Debian, но достаточно сильно открытый из знакомых мне с поддержкой компании. >archlinux - каюсь, упустил, развивается проект Кто бы их только ещё отговорил P2P-клиенты натравливать на зеркала... :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	179. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от sHaggY_caT (ok) on 03-Ноя-09, 17:30
	>ubuntu, fedora, opensuse, mandriva - тут балом правят большие босы, за что >они платят то и делают разрабы. Перестанут платить, например марк забросит >убунту, и все фактически смерть - пока там наберется рабочее комьюнити(если >наберется вообще), пока найдут финансирование  core-team (тех кому нужны результаты >работы не вразрез комьюнити)........... А так ли это страшно, как Вы рисуете :)? Имхо, нашим миром правят деньги, и, имхо, большинство успешных OSS проектов имеют компанию-покровителя. Все-таки некоторые вещи в коммьюнити делают хуже, чем в рамках компании-разработчика(тот же дизайн архитектуры решения, просто дизайн интерфейса для конечных пользователей, и т д). Имхо, коммерческая компания, делающая бизнес на OSS разработках, кровно и финансово заинтересованная в успехе своего (и коммьюнити) решения, более жизнеспособна, чем какое-то отдельно взятое коммьюнити. Речь, конечно, не про таких монстров, как FreeBSD или Debian, но мы столько раз наблюдали развал коммьюнити из-за того, что люди в нем просто переругались, и не нашелся никто, кто бы их смог образумить... При том, что к Debian, как к решению отношусь очень хорошо (считаю его даже лучшей ОС после RHEL/CentOS на свой личный взгляд), наоборот, предпочту систему, у которой есть более продвинутая коммерческая версия, или такая же, но с поддержкой. Стоит вспомнить про ту же Zimbra, про тот же Zenoss, про тот же Zabbix, конечно, на вкус и цвет товарищей нет, но многим эти решения нравятся больше, чем OpenGroupware или Nagios, кажутся более стройными, логичными, понятными, предсказуемыми, и документированными. ALT Linux'у Салют) Всяких Вам удач! UPDATE: у OpenGroupware есть компания разработчик, не только коммьюнити, но не суть
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	181. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Michael Shigorin (ok) on 03-Ноя-09, 17:34
	>мы столько раз наблюдали развал коммьюнити из-за того, что >люди в нем просто переругались, и не нашелся никто, кто бы >их смог образумить... В точку! >ALT Linux'у Салют) Всяких Вам удач! Спасибо, передам им :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	131. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от амонинус on 02-Ноя-09, 13:51
	А вы никогда не встречали гентушников, которые были убеждены, что линукс на их компьютере быстрее, чем у них работать не может, ибо у них генту и под их железо оптимизирована? А ведь при неоптимальной компиляции генту будет работать медленнее, чем убунту и чем что угодно. Если гентушник неопытный, он может все скомпилять неправильно, решить, что лучше некуда и сидеть, кушать кактус.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	141. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Daltinn (ok) on 02-Ноя-09, 15:49
	>мое общение с убунтоводами достаточно печально, причин много: не у всех так-же печально... У меня есть знакомые использующие убунту (на десктопе) после генту и фри, потому-как некогда на своем десктопе заниматся компиляцией и настройкой того, что в бубунте изначально работает, да и сам сижу под убунтой. При этом сервера на FreeBSD, RHEL. Это я к тому, что не надо всех по шаблону мерять, шаблон может кривой попастся. >гента имеет плюс хотя бы в том, что она заставляет подумать. Респект. Сам советую фряху новичкам, кто не просто побаловатся, а систему изучить. И начинал с установки Фри в качестве десктопа, и полным отсутсвием виндов. Захотелось фильм посмотреть - читаеш, настраиваеш, приходит понимание процесса... >важна не ОС а те руки которые к ней допущены. Полностью согласен, и хочу добавить, что ОС выбирается исходя из задачи, ибо нельзя лошадь впереди телеги ставить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	153. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от амонинус on 02-Ноя-09, 18:45
	>Полностью согласен, и хочу добавить, что ОС выбирается исходя из задачи, ибо >нельзя лошадь впереди телеги ставить. Вы, по ходу перепутали. Лошадь именно так и ставят... На нагруженных серверах-то, конечно, ось исходя из задачи выбирают, а на десктопе все обычно наоборот делают. Ось ставят, а на нее уже прикладной софт под задачи.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	163. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от pavlinux (ok) on 03-Ноя-09, 06:56
	>>ибо нельзя лошадь впереди телеги ставить. >Вы, по ходу перепутали. Лошадь именно так и ставят... Не, это умная лошадь, - смотрит что везёт. :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	171. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от Карбофос (ok) on 03-Ноя-09, 12:20
	> ибо нельзя лошадь впереди телеги ставить. kernel panic
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

70. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
Сообщение от mma on 01-Ноя-09, 15:47
Сколько убунтологов собралось уверенных в трушности своего дистра. Неужели вам дальше CFLAGS  приемуществ генты не видно?  Все уперлись обезъяннюю компиляцию и флаги, хотя это адлеко не главное.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	102. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от khz on 01-Ноя-09, 23:35
	>Сколько убунтологов собралось уверенных в трушности своего дистра. Неужели вам дальше CFLAGS > приемуществ генты не видно?  Все уперлись обезъяннюю компиляцию и >флаги, хотя это адлеко не главное. Сходи, покомпилируй, что-ли. Может у тебя кде грузиться на 0.03 сек начнет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	104. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от аноним on 01-Ноя-09, 23:37
	>Сходи, покомпилируй, что-ли. Может у тебя кде грузиться на 0.03 сек начнет. Или фильм сходится за ночь, а не за сутки. Вы так уязвлены и это так видно...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	111. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от mma on 02-Ноя-09, 07:55
	>>Сходи, покомпилируй, что-ли. Может у тебя кде грузиться на 0.03 сек начнет. > >Или фильм сходится за ночь, а не за сутки. Вы так уязвлены >и это так видно... Никапли, просто смешно когда люди говорят о том чего толком не знают
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	113. "Оценка влияния флагов оптимизации GCC на производительность ..."		–2 +/–
	Сообщение от h0h0l on 02-Ноя-09, 09:21
	да, этого безусловно можно достичь исключительно в Генту. Фильм случаем не о пользе каждодневной компиляции правой рукой для растущего организма?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	125. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от anonymous (??) on 02-Ноя-09, 11:25
	низко
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

81. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
Сообщение от Aesthetus Animus on 01-Ноя-09, 17:24
Читаю обсуждение и не могу понять, чего так ЛОРом воняет?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от empty on 01-Ноя-09, 17:37
	>Читаю обсуждение и не могу понять, чего так ЛОРом воняет? Вот из-за этого - http://www.opennet.dev/openforum/vsluhforumID3/60473.html#5
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	128. "Оценка влияния флагов оптимизации GCC на производительность ..."		–1 +/–
	Сообщение от Michael Shigorin (ok) on 02-Ноя-09, 11:34
	>>Читаю обсуждение и не могу понять, чего так ЛОРом воняет? Да вот... пользуйтесь ссылкой "сообщить модератору" :( >Вот из-за этого - http://www.opennet.dev/openforum/vsluhforumID3/60473.html#5 Боюсь, скорее из-за http://www.opennet.dev/openforum/vsluhforumID3/60473.html#4
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	146. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
	Сообщение от empty on 02-Ноя-09, 16:29
	Нет именно из-за этого. А если в дискуссии использовать размахивание банхаммером в качестве аргумента, то сходство становится вообще один-в-один. Для модератора предвзятость - очень большой недостаток.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	178. "(offtopic) флеймообразование"		+/–
	Сообщение от Michael Shigorin (ok) on 03-Ноя-09, 17:25
	>Нет именно из-за этого. В смысле обсуждения Правильного Именования 64-битной архитектуры, обратно совместимой с x86?  Так там ерунда была, можно сказать, незнание справочных данных. >Для модератора предвзятость - очень большой недостаток. Вот потому и отказывался довольно долго.  Согласился только при очередном нашествии матерящихся.  А потёр после предупреждения, поскольку "провокация флейма и совсем пустые выкрики", см. http://wiki.opennet.ru/Moderator
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

158. "Оценка влияния флагов оптимизации GCC на производительность ..."		+1 +/–
Сообщение от xaljava on 02-Ноя-09, 20:09
Понял вот что: Система управления пакетами Gentoo даёт больше свободы, но с этим связано много трудностей как разработчиков, так и пользователей. И это абсолютно нормально. Уже сложил мнение, что Gentoo-шники относятся ко всему остальному Linux-сообществу как оно относится к Windows-племени (в хорошем смысле), то есть идеи, заложенные в создание и развитие Gentoo на порядок выше и ещё дальше от принципа "Папа сделал, папа дал". (сам Gentoo не ставил и не видел ни разу; как от военкомата откошу и работу поменяю, обязательно поэкспериментирую) При том, если Gentoo понравится, а это несомненно произойдёт, использовать Debian, писать скрипты для apt/dpkg и проч. никто не запретит!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	172. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Карбофос (ok) on 03-Ноя-09, 12:34
	как можно в хорошем смысле гнуть палцы? ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	176. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от xaljava (ok) on 03-Ноя-09, 16:11
	>как можно в хорошем смысле гнуть палцы? ;) У я смельчак =)))) Видали ?! А я ещё и не так могу !! грешу антисмысловыми оборотами =) Имел в виду, что ни от груш, ни от яблок отказываться не собираюсь... То бишь, использую как Linux(debian), так и Windows(XP).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	191. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Карбофос (ok) on 04-Ноя-09, 16:15
	мне тоже приходится иногда работать на виндах - искать ошибки в старых проектах, но от новшеств майкрософта (навязывание стандартов, несовместимость продуктов) я прихожу в тихий ужос.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	192. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от xaljava (ok) on 04-Ноя-09, 18:43
	>мне тоже приходится иногда работать на виндах - искать ошибки в старых >проектах, но от новшеств майкрософта (навязывание стандартов, несовместимость продуктов) я прихожу в тихий ужос. Мне также видится эта картина, но одним энтузиазмом сыт не будешь, рынок диктует, а найти подходящую работу непросто, особенно, когда по институтской и школьной программам кроме TP7 в области программирования за плечами ничего не имеешь... Моё дилетантское мнение, что Windows хороша "снаружи" (те программы, что под неё пишутся), а Linux хорош изнутри (ядро, организация системы) говорит, что Microsoft занимает более выгодную позицию по отношению к пользователю и уже может ничего не делать (а может быть они этим и занимаются уже), увы =( Иными словами, тут уже даже не от самой MS зависит, а от окружающего её мира разработки. Чтобы MS уйти с арены, ей самой надо сильно напрячься и довести свою ОС до полностью нерабочего состояния. А мир разработки ориентируется на $-оллар и менее зависим от всего остального. Простой пользователь вообще ни на что не ориентируется, разве что на мировоззрения, рекламу и свой кошелёк. Отсюда мой банальный вывод: Всё зависит от разработчиков ПО - будут писать нативные приложения под Linux - займёт последний место на десктопах, не будут - Linux так и останется осью для серверов/роутеров и специфичных задач вроде распределённых вычислений! Исключения останутся исключениями, не более...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

173. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
Сообщение от BlackRu on 03-Ноя-09, 13:32
И что вы наехали на бедную Gentoo? Что там долго ставится? Если сравнить суммарное время настройки Gentoo и Ubuntu, то Gentoo быстрее. Причина - когда уже опыт есть - проблемы - не кажутся проблемами и решаются в две минуты. Однако на решение тех же ситуаций у Ubunto-ло-логов уходит в среднем пару суток и периодически в его голове - убутолога - проскакивает: "ну, может надо было все-таки Server Win2003 поставить, я ведь в нем разбираюсь". В Gentoo, единственное - Office долго собирать.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	174. "Оценка влияния флагов оптимизации GCC на производительность ..."		+/–
	Сообщение от Аноним (??) on 03-Ноя-09, 14:45
	Товарисч, для Gentoo уже довольно долго есть бинарные сборки OpenOffice
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема