The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Оценка влияния флагов оптимизации GCC на производительность ..., opennews (??), 31-Окт-09, (0) [смотреть все]

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


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

в debian-based системах никогда с этим проблем не наблюдал.

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

Ответить | Правка | Наверх | Cообщить модератору

32. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от DFX (?), 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), 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 +/
Сообщение от аноним (?), 01-Ноя-09, 18:21 
Ну я знаю контору, там 300+ машин под генту. Если вы думаете, что они все что-то собирают, подумайте еще раз. Често говоря, устал спорить с людьми, у которых в мозгу до сих пор стойкая ассоциация gentoo=бесконечная сборка. Самим-то не смешно? Gentoo как минимум позволяет легко собрать и настроить болванку под любые нужны, протестировать и разложить. Установка на целевую машину будет быстрее чем ваши бесконечный "cборки" убунты, потому что код эффективней и размер меньше, по большей части из-за отсутствия ненужных депендов.

Да и, кстати, возьмите любую контору, где используется FreeBSD. Сюрпрайз-сюрпрайз, там тоже все из исходников.

Ответить | Правка | Наверх | Cообщить модератору

93. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от sHaggY_caT (ok), 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 +/
Сообщение от аноним (?), 01-Ноя-09, 23:32 
>Нет, кажется, Вы не понимаете :) Gentoo и удобство массовой установки не
>очень совместимые понятия)

Вот именно вы и не понимаете, видимо потому что не пробовали. Не пробовать простительно, а говорить про то, что не пробовали - непрофессионально.

>погуглите по словам kikstart, jumpstart, PXE, Anaconda, Cobbler...

Мда, свалить совершенно разные вещи в одну кучу... Что, по-вашему, gentoo и собранные под себя пакеты отменяют любую технологию массовой установки/развертывания?

>И Вам станет стыдно, что Вы про какие-то болванки

Да что с вами говорить... Под болванкой подразумевается образ для загрузки по сети.

Ответить | Правка | Наверх | Cообщить модератору

105. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от sHaggY_caT (ok), 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 (??), 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), 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 (??), 02-Ноя-09, 14:47 
>>Угу. А еще адекватнее - во RHEL. Так адекватно, что они до
>>сих пор на вусмерть бекпортированном 2.6.18 сидят.
>
>Так это же хорошо :) ABI в версии сохраняется, железным вендорам удобнее
>писать драйвера под свои raid-массивы, контроллеры, и др. железки.

А потом при смене версии дистрибутива - хрясь! И мы больше не видим RAID, система накрывается медным тазиком! А бекапы на рейде! А дрова - только в новых ядрах! А новых ядер в новом дистрибутиве нет!
Я конечно преувеличиваю, но бич бинарного дистрибутива - ты не обновишь его после прекращения срока поддержки. Он одним махом превращается в хлам. Бэкпортить - это великое зло драйверописателей. Вместо того, чтобы перепилить драйвера под новый ABI и получить от этого профит в виде свежих драйверов для свежего ядра, они зашориваются на конкретной версии, а потом хоба - и вдруг железки становятся нерабочими. Железным вендорам удобнее запихивать свои драйвера в ядро, чтобы вместо них в последствии работали люди Линуса.

Ответить | Правка | Наверх | Cообщить модератору

137. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от pavel_simple (ok), 02-Ноя-09, 15:07 

>Я конечно преувеличиваю, но бич бинарного дистрибутива - ты не обновишь его
>после прекращения срока поддержки. Он одним махом превращается в хлам.

ну все вышесказанное уместно лишь в случае если upgrade провести ну ни как не получается - а это нужно придумать кучу доводов.

обновление с

Debian 3 на 4 прошул на ура
С Debian 4 на 5 анологично.

так зачем мне использовать неподдерживаемый дистрибутив если его можно проапгрейдить?

P.S. постоянный bleeding edge в Debian тоже присутствует.

Ответить | Правка | Наверх | Cообщить модератору

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

148. "Оценка влияния флагов оптимизации GCC на производительность ..."  +1 +/
Сообщение от empty (?), 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

Помните из старого совецкого фильма - "Чтобы быть женой генерала, нужно выйти замуж за лейтенанта"

Советую взять на вооружение ;)

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

122. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 02-Ноя-09, 11:17 
>http://www.calculate-linux.ru/Calculate
>Нет или не искала? А может вообще не в теме???

Я с ними общался (попросили сделать зеркало на ftp.linux.kiev.ua) и осталось довольно странное впечатление: люди явно грамотные, но будто варящиеся в своём соку скорее изолированно.

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

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

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

Calculate, в общем-то, самобытный дистрибутив и очень молодой. И они действительно изолированы, так как нет сформировавшегося сообщества и он ориентирован на русскоговорящих пользователей (для развития дистрибутива - это минус). Однако их идеи - сеты установки, допил обновлений, CLS - очень и очень перспективны для Gentoo.

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

А я знаю больше добрых, ласковых и теплых :)).

Ответить | Правка | Наверх | Cообщить модератору

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

И даже признаётесь. И про BSD и про методы развёртывания. стыдно

И кто там начал мерятся серверами, а ?

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

186. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от sHaggY_caT (ok), 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 (?), 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 !"

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

187. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от sHaggY_caT (ok), 04-Ноя-09, 10:31 

>в нашей стране не покажу, к сожалению, засилье братского и ненавистного BSD
>не даёт.

У хостера 1Gb Linux'овые серверы на Gentoo. Сколько у них серверов, не знаю, но судя по рейтингу на 1stat.ru, с проблемами управляемости инфраструктуры они должны были столкнуться.

У них же есть Apache в production на Windows.

Хочется повторить ту же фразу про "если нельзя, но хочется" :))

Ответить | Правка | Наверх | Cообщить модератору

188. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от Michael Shigorinemail (ok), 04-Ноя-09, 11:29 
>а что вы таки имете против моего ноутбука ?

Ничего, окромя того, что localhost -- это очень узкий взгляд почти на любые вещи.

>у него ещё есть 3 друга, которые ему помогают, но к делу
>это не относится.

У меня только в этой комнате пять хостов, не считая точки. :)  И не говоря о серверах и контейнерах.  Самый старенький бук, которому пора на пенсию, представлял бы заметные проблемы по локальной сборке, а тонкий клиент в любом случае администрируется в BIOS (и в рамках терминального сервера).

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

>ещё не могу понять отчего Альтовцы, тут высказывающиеся

Пока _тут_ таких высказавшихся наблюдаю одну штуку в своём лице.

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

Как раз наоборот: такое ощущение, что Вы тратите уйму времени на окучивание аж самого себя.  Вспоминают же людей, которые при жизни успели сделать многое для _других_.  Разумеется, дело сугубо личное, но раз уж непонятно...

>какие такие другие люди будут пользоваться системой с моих ящиков ?

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

А себе любимому... простите, но это-то к какому делу относится?

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

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

Зеркальная генту болезнь ?

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

121. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 02-Ноя-09, 11:12 
>ну незнаю, дурачинка, как насчёт всех библиотек, которые можно подгружать не только
>по необходимости (аки -Wl,--as-needed)

Прекратите ругаться на собеседника и марш читать, чем на самом деле занимается --as-needed (hint: на стадии линковки, о чём говорит и -Wl, а не в рантайме).

>но и вообще выборочно выпилить при конфигурации сборки ?

В альте многие пакеты обвешены несколькими, а то и кучей, %def_with/without -- и можно собрать нужное путём rpmbuild -ba --with фича.  USE-флаги отличаются от этого добавлением унифицированного пространства имён и инфраструктуры его использования, но технически ничто не мешает сделать то же самое для пакетных дистрибутивов (по крайней мере некоторых).  Видимо, просто нужда преувеличена -- а у кого она реальная, для тех уже есть генту.

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

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

>покажите мне, страна должна знать своих кретинов!

Давайте оставим процитированное здесь сообщение, пусть знает.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

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

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

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

нукась, ldd `which konqueror`

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

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

уппсс...

Ответить | Правка | Наверх | Cообщить модератору

180. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Ноя-09, 17:32 
>$ ldd 'which konqueror'
>ldd: ./which konqueror: Нет такого файла или каталога

Копипастом надо было или присмотреться -- pavlinux написал бэктики (backticks, обратные одинарные кавычки -- живут вместе с тильдой), а Вы взяли апостроф и вместо результата работы команды which konqueror подставили строчку из двух слов и пробела между ними.

Ответить | Правка | Наверх | Cообщить модератору

182. "Оценка влияния флагов оптимизации GCC на производительность ..."  +1 +/
Сообщение от pavlinux (ok), 03-Ноя-09, 19:03 
>$ ldd 'which konqueror'
>ldd: ./which konqueror: Нет такого файла или каталога
>
>уппсс...

ldd $(which konqueror) | grep lib[g]

Какой же такой сИкретный браузер у Вас под KDE, без Glib зависомостей.???

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

189. "Оценка влияния флагов оптимизации GCC на производительность ..."  +/
Сообщение от Michael Shigorinemail (ok), 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 (?), 01-Ноя-09, 15:54 
> если у вас имеется конкретика - милости просим. Какие такие зависимости нельзя обойти в дистрибутивах основанных на пакетной системе?

1. Бэкпорт ряда тяжеловесных приложений в стабильный резиз Debian. Извольте сделать это с минимальным коэффициентом (в сравнении с генту), равным гемор*время.    
2. Установка разных версий одного и того же приложения.
Ну, это на вскидку.

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

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

1) ололо! backports.org
2) А зачем? Хоть один реальный пример?
Очередной вброс воинствующего гентушнега?

Ответить | Правка | Наверх | Cообщить модератору

103. "Оценка влияния флагов оптимизации GCC на производительность ..."  +2 +/
Сообщение от аноним (?), 01-Ноя-09, 23:36 
>1) ололо! backports.org

Ололо, а теперь попробуйте оттуда поставить что-то, что требует новой версии уже установленной библиотеки. А потому все это еще и обновить. Вот тут ололо и начнется.

>2) А зачем? Хоть один реальный пример?

Разные PHP и перлы на хостинге. Мало? Несколько версий библиотеки для тестирования совместимости с ней своей программы. Установка в ~ или временную директорию.

Ответить | Правка | Наверх | Cообщить модератору

123. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 02-Ноя-09, 11:22 
>>2) А зачем? Хоть один реальный пример?
>Разные PHP и перлы на хостинге. Мало?

Контейнеры.  Вообще-то на хостинге они как бы обязательны, даже для dedicated -- чтоб не отдавать всю систему сразу при проломе чужого кода, который весь никак не проаудитишь.  Так что не то что мало, а пример против Вас работает.

>Несколько версий библиотеки для тестирования совместимости с ней своей программы.
>Установка в ~ или временную директорию.

Чруты, контейнеры, виртуалки, сборка влево.  В альте можно удобно сделать нужное изолированное окружение при помощи hasher и в ём же и запустить свою софтинку (hsh-run).

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

138. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от pazkeemail (?), 02-Ноя-09, 15:15 
> И кто это потом поддерживать будет?

А генту у вас таинством небесным сама собой поддерживается ?

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

chroot /jail apt-get upgrade замечательно работает.

Ответить | Правка | Наверх | Cообщить модератору

177. "Оценка влияния флагов оптимизации GCC на производительность ..."  –1 +/
Сообщение от sHaggY_caT (ok), 03-Ноя-09, 17:19 
>Чруты любой накидать сможет, а обновлять кто будет? Это ваше изолированное окружение - >как его поддерживать в актуальном состоянии?

Puppet, в его сегодняшнем виде, способен сэкономить время системного администратора, и позволить одному человеку поддерживать сотни хостов(физических и виртуальных) в актуальном и допиленном состоянии )

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

Есть и другие решения, помимо паппета, тот же Sattelite, например) Он, конечно, не очень UNIX-way, но позволяет, через SQL-запрос, представить в удобоваримом виде, какие пакеты стоят в каких системах, даже если хостов десятки тысяч)
Такой же удобный централизованный менеджмент всех этих тысяч хостов (пересетапы, развертывание по PXE, обновление дырявых пакетов после появляения пакета с фиксами(или его самостоятельной сборки))

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

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

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

и хоть бы веть один генту вживую видел - нет. будем много говорить о том как мы не хотим и "оно сложна и нипанатнааа"(c).

ядро, собраное в генте _своими_ руками тоже упорно не грузится по PXE ? как же такое ядро прошло QA-тестирование до ваших кластеров ?

Ответить | Правка | Наверх | Cообщить модератору

190. "цена рекомендации"  +/
Сообщение от Michael Shigorinemail (ok), 04-Ноя-09, 12:08 
>я смотрю, вас, бедненьких, прямо самолично заставляют поддерживать

Да не в том дело, что "заставляют".  А в том, что отдельно взятая молодёжь, размахивая шашкой, не соразмеряет пользы и вреда.

В своё время дошло, что рекомендуя что-либо людям -- будь готов _сам_ поддержать советом.  Не сослаться на "сообщество", а _сам_ потратить время на вот этого человека.  Знаете, очень хорошо вправляет мозги по части времяёмких рекомендаций. (причём для некоторых применений я бы порекомендовал посмотреть как раз на LFS/Gentoo, а не на пакетные дистрибутивы -- при наличии оснований полагать, что там времени больше сожрут последние)

Понимаете, одно дело говорить "у меня всё работает" (в уме -- на локалхосте).  А другое, когда кто-нить из начинающих админов, на которых начальство свалило задачу "к понедельнику шоб был сервер" -- поверит кому попало и угробит время сперва чтоб получить втык и ещё неделю времени, а затем и ещё несколько лет до осознания того, что вообще-то тот кто-то на форуме был неправ применительно к данной ситуации.

>как же такое ядро прошло QA-тестирование до ваших кластеров ?

Ядра Gentoo не проходили QA "до наших кластеров".  Вообще ещё на кластерах оного видать не доводилось.

PS: да видел я вашу генту, видел.  И слакварь видел.  Не волнуйтесь так.

Ответить | Правка | Наверх | Cообщить модератору

193. "цена рекомендации"  +/
Сообщение от AlexanderYT (?), 04-Ноя-09, 21:59 
>Понимаете, одно дело говорить "у меня всё работает" (в уме -- на
>локалхосте).  А другое, когда кто-нить из начинающих админов, на которых
>начальство свалило задачу "к понедельнику шоб был сервер" -- поверит кому
>попало и угробит время сперва чтоб получить втык и ещё неделю
>времени, а затем и ещё несколько лет до осознания того, что
>вообще-то тот кто-то на форуме был неправ применительно к данной ситуации.
>

Сие понятно. Но вернемся что ли к десктопам. В начале этого года или в конце прошлого в пакетные дистрибутивы начали активно пихать пульз, особо в те, которые курируются "корпорациями". Сейчас моду  на пульз подхватили и догоняющие. Вы наверное видели, сколько людей про пульс говорят "лестных" слов?  Так вот статистика моя скромная говорит от том, что время, потраченное на выковыривание пульза из дистрибутивов на которых я сидел (а надо было, ибо без звука на десктопе скучновато) в  сумме больше, чем я потратил на первую тестовую установку десктопа на Gentoo, а потом уже на повторную и окончательную (и конечноже с USE=-pulseaudio).
А может вы еще сталкивались с пакетами в стабильном дистрибутиве, которые имеют версию 1.2 например, и данная версия имеет багу, которая именно вам мешает нормально с ней работать. И что мы видим? Оказывается, сия бага исправлена в версии 1.3, но в этот монолитный пакетный дистрибутив эта версия попадет только в случае с бэкпортом (либо слезно просить мантейнера, что бы он пофиксил текущую версию). А сколько времени надо на бэкпорт приложения, который глубоко интегрирован в систему? Через пару суток вы поймете, что ваша система превратилась в адский микс stable и testing, а результат не достигнут.

  

Ответить | Правка | Наверх | Cообщить модератору

194. "обновление софтового стека"  +/
Сообщение от Michael Shigorinemail (ok), 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 (?), 02-Ноя-09, 01:58 
В принципе вам уде ответили, но тем не менее

>1) ололо! backports.org

Там далеко не все что может потребоваться, так что не 100% панацея.

>2) А зачем? Хоть один реальный пример?

Опять же вам ответили, но добавлю еще: установка необходимого пакета, который требует python древней верии (вот такие капризы у разрабов в 21 веке)

>Очередной вброс воинствующего гентушнега?

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

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

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

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру