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

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

Не уходите от вопроса: что вслучае ошибке должна делать "настоящая" автоматизация? То что в идеальном дистрибутиве ошибок нет - это мы все в курсе.

>Постоянно означает каждый раз при обновлении ядра.

Ну, 2-3 раза в месяц (если гнаться за свежестью ядер) можно и подправить. А если на ~arch сидеть, так и ещё реже.

>> А Вы не пробовали нажимать h когда делали make oldconfig?

>Нет.

Зря, там краткое описание пункта выводиться ;)

>Ничто не мешает. Только вместо костылей и бесполезной сборки проще и быстрее поставить qemu из бинаря.

При чём здесь gentoo?

>Потому что мантейнеры забили на автоматизацию обновлений и скинули заботу об обратной совместимости на юзера, вместо того, чтобы сделать скрипты миграции как в debian?

Попробуйте подумать ещё.

> Я могу заменить один GPU на другой. Например я заменил слабо поддерживаемый ATI на хорошо поддерживаемый NVidia.

От этого openoffice и FF не стали использовать все конвейеры GPU на 100%.

> С процессором Вы почему-то этого не делаете.

А зачем? Сделать это несложно.

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

Это уже напоминает параною. Вот здесь и могло быпроявиться реальное преимущество кода, вы бы могли прислать разработчикам патчи для более эффективного использования железа.

> Нет, потому как эффективность у моего железа высокая.

Ну как же она высокая если тот же браузер ожидает ввода 99% своего времени.

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

Тем самым искуственно снижая эффективность железа.Ну и в чем тогда смысл иметь процессор с архитектурой AMD64 и использовать его в режиме энергосбережения? Все это я говорю к тому, что из-за того, что все возможности SIMD и GPU не используются ping-ом, tracert, firefox, openoffice и т.д. не следует необходимости срочно выкидывать SSE или GPU.

>> Вменяемый человек понимает, что использовать железо на 100% не удастся никогда кроме случаев сферических коней в вакууме и спокойно живет с этой мыслью.

> Почему-то мне это напоминает: "что дали, то и жрите"...

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

> Общий ответ - для совместимости и более быстрой работы (фактически увеличивается количество регистров).

Для совместимости есть FPU. А -mfpmath=sse, генерирующий скалярные SSE-инструкции почему-то на другом синтетическом тесте nbench не дал никакого прироста по числу операций с плавающей точкой. Думаю, что FPU, тянущий хвосты совместимости с i387 в будущем попросту выкинут, компилятор наконец нормально научится запараллеливать(вектризовать) операции с плавающей точкой(-ftree-vectorize), но в любом случае понадобятся скалярные операции когда векторизация невозможна. А число регистров SSE банально увеличат. Их уже увеличили в арх-ре AMD64 в два раза.

> Не уходите от вопроса: что вслучае ошибке должна делать "настоящая" автоматизация?

Корректировать ошибку если может с ней справиться(примеры: CRC,ECC,система стабилизации ESP,аппаратный watchdog ребутящий систему в случае зависания) и останавливать работу если не может. А если автоматика впадает в ступор даже от банальной необходимости использовать gcc-3 для сборки qemu, экспортировать базу ldap и импортировать обратно, не умеет перезапускать обновленные сервисы это означает, что автоматизация низкая. Это как охранник в будке нажимающий на кнопку чтобы открыть шлагбаум когда ему сигналят в сравнении с ИК-ключем. Или как бабушка на вахте, записывающая приходящих автоматической шариковой ручкой, в сравнении с автоматизированной системой контроля доступа с электронными пропусками, турникетами, записью событий и видео с камер в базу и массой сервисных функций.

> Ну, 2-3 раза в месяц (если гнаться за свежестью ядер) можно и подправить. А если на ~arch сидеть, так и ещё реже.

0 раз комфортнее.

> Зря, там краткое описание пункта выводиться ;)

Обычно после make oldconfig я делаю make xconfig. От необходимости врчную проверять не произошли ли изменения опций конфигурации(я уже приводил примеры ip(4|6)tables->xtables, ip_conntrack->nf_conntrack) не избавляет. Упустил что-то из виду - получил проблему. Человеческий фактор. И чем этого фактора меньше тем лучше. Человек должен думать, машина работать. (с) IBM

>>Ничто не мешает. Только вместо костылей и бесполезной сборки проще и быстрее поставить qemu из бинаря.

> При чём здесь gentoo?

Ничто не мешает и в федоре косяки постоянно исправлять, тестируя для RedHat альфаверсию RHEL. А еще никто не мешает собирать сорсы по configure&&make и вручную удовлетворять зависимости, только вы почему-то выбрали Gentoo. Вот и меня ручной труд там где с ним справляется автоматика и неоьходимость уделять системе повышенное внимание не устроила. Поэтому и была произведена замена Gentoo на более автоматизированный инструмент.

>>Потому что мантейнеры забили на автоматизацию обновлений и скинули заботу об обратной совместимости на юзера, вместо того, чтобы сделать скрипты миграции как в debian?

>Попробуйте подумать ещё.

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

> Т.е. к Вашему P4 2,8 это не относиться - это раз.

При основании проекта, возможно тогда таких еще и не было.

> Ещё раз спрашиваю: почему используются свои костыли? Явно не потому что они быстрее на устаревших процессорах...

Вопрос явно не ко мне, а к авторам.

> Интересный вывод! Вы только mplayer-ом пользуетесь для проигрывания DVD?

Да.

>>Слабенькой еле заметной оптимизации.

>Однако она есть. Вы же не будете утверждать, что liboil заметно ускоряет запись дисков gnomebaker-ом?

Оптимизация в работе gnomebaker от использования liboil тоже есть. Зачем тогда было возмущаться? :) Приведенный в топике пример показывает что польза от сборки с -mfpmath=sse есть, собранный с разными флагами nbench показывает что ее нет.

> Я тоже не смогу. Для этого нужен тестовый стенд.

Подсказка: тестовую систему можно развернуть в chroot.

> Я надеюсь, что теперь Вам понятно, почему все серьёзные рассчётные инструменты требуют ручной сборки?

Ставим процессор с архитектурой AMD64, бинарный AMD64 дистрибутив и не паримся.

> И мы приходим к самому интересному вопросу: как видно из cpu-бенчмарков, скорость достаточно серьёзно возрастает, так почему же этого возрастания не видно на реальных приложениях?

А этого никто не знает, разве что сами создатели процессоров. Но оно было заметно ещё во времена athlon vs p4. В синтетике p4 обгонял атлона почти вдвое, в реальных приложениях атлон был зачастую даже быстрее чем p4.

Я админил несколько сот промышленных серваков с дебианом. Так вот, на всех серверах у нас были самосборные ядра. Например на машинах с серьёзным I/O надо было отключать iptables.

Мы никогда не использовали официальные версии mysql, apache и php . В каждом случае были причины, по которым они не подходили. Все эти пакеты были самосборные.

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

И в этом случае лучше иметь развитую систему управления зависимостями при сборке. Ни один бинарный дистрибутив, в том числе и дебиан, не имеет такой инфраструктуры, хотя создать её не сложно. apt-source и apt-build плохие инструменты для самосборки, они рекурсивно ни какие зависимости не отслеживают, и не компилируют.

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

Мы оба, по каким то причинам, не хотим держать в системе ещё одну версию gcc которая нужна для сборки qemu. По этому он qemu собирает, как я понял, в virtualbox, а я на время сборки переключаю профиль.

В Генто есть свобода выбора и каждый может выбрать что ему кажется правильным и удобным.

>Это ты о Микрософте так лестно отзываешься, что ли?

Это я об free software, а вот вы в своих доводах здесь и философии явно на некрософт смотрите!

>Я пока еще не заметил автоматизации никакой.

Ты не там смотришь. Возьми Генто и увидишь.

>Один унылый пятизвездочник говорит, что можно 100 копий друпала автоматом поставить,

В Генто есть система слотов которая разрешает ставить множество версий одного пакета, а в Генто всё автоматом ставится, даже с исходников.

> и что в генту какая-то волшебная русификация, которой в других дистрибутивах нет,

В пинципе я так понял что в Убунту русификацию покорявили... В Генто русификация пакетов берётся с сайтов где эти пакеты разрабатываются, переводятся. Может перевод и версия программы быть свежее. А локализацию в Генто каждый делает сам, как считает нужным и правильным, есть доки...

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

А ты посмотри в portage на любом сайте, выбираешь app-office/openoffice там есть инструкции сборки openoffice-*.ebuild с ссылками на патчи а в директории app-office/openoffice/files/ или distfiles/ эти патчи можно и посмотреть. Кстати патчи, и портирование на разные архитектуры - это то что Генто возвращает разработчикам программ - сообществу.

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

Я ситуацию с qemu тебе объяснил выше в этом посте, хочешь попробывать Генто - ставь, не хочешь тебя ни кто здесь не агитирует...

>................. и не компилируют.

Тссссс. Им их религия компилировать запрещает, грех у них это большой! А ты, исходя с их суждений, отступник пересобравший ядро, апач, мускуль и пихпих...... ;)

>Мы оба, по каким то причинам, не хотим держать в системе ещё одну версию gcc которая нужна для сборки qemu. По этому он qemu собирает, как я понял, в virtualbox, а я на время сборки переключаю профиль.

>В Генто есть свобода выбора и каждый может выбрать что ему кажется правильным и удобным.

Я в дебиане могу иметь две версии gcc, могу иметь qemu вообще без установки gcc, получается в дебиане вариантов "свободы" больше?

>там есть инструкции сборки openoffice-*.ebuild с ссылками на патчи а в директории app-office/openoffice/files/ или distfiles/ эти патчи можно и посмотреть

То есть получается, с этими же патчами можно собрать опенофис где угодно?

>это то что Генто возвращает разработчикам программ - сообществу.

Впервые слышу, что Генту приносит какую-то пользу. Можно ссылку, подтверждающую это?

>хочешь попробывать Генто - ставь, не хочешь тебя ни кто здесь не агитирует...

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

>От этого openoffice и FF не стали использовать все конвейеры GPU на 100%.

А Вы, как я гляжу, всё ещё мыслите категориями "liboil ускоряет запись дисков gnomebaker'ом"...

>А зачем? Сделать это несложно.

Вот я и спрашиваю: почему Вы этого не делаете? Или, например, отключите 3D ускорение, ведь далеко не все GPU его поддерживают в той или иной мере.

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

Сделать это для "alpha amd64 arm hppa ia64 mips ppc ppc64 sh sparc x86 ~x86-fbsd" я не смогу. Меня устраиват оптимизация gcc. А Вы вольны делать всё что хотите.

>Ну как же она высокая если тот же браузер ожидает ввода 99% своего времени.

>Тем самым искуственно снижая эффективность железа.Ну и в чем тогда смысл иметь процессор с архитектурой AMD64 и использовать его в режиме энергосбережения? Все это я говорю к тому, что из-за того, что все возможности SIMD и GPU не используются ping-ом, tracert, firefox, openoffice и т.д. не следует необходимости срочно выкидывать SSE или GPU.

У Вас есть очень хорошая методика оценки эффективности? Прошу её огласить.

>Почему-то мне процесс выжимания производительности без оценки эффективности и целесообразности, горевание по каждой бибилиотеке и программе, которая неэффективна(а это все программы), тем более на арх-ре AMD64 под которую любой бинарный AMD64 дистрибутив уже максимально оптимизирован, какой-то параноей.

А Вы всё это оцениваете так же как и расход электроэнергии?

>Приходится заниматься самосборкой, самостоятельно занимаясь борьбой с зависимостями

Так чем не устраивают средства debian?

>apt-source и apt-build плохие инструменты для самосборки

Доказательства?

>они рекурсивно ни какие зависимости не отслеживают, и не компилируют.

?????

Я правильно понимаю, что на "промышленные серваки" Вы предлагаете ставить gentoo?

>Корректировать ошибку если может с ней справиться(примеры: CRC,ECC,система стабилизации ESP,аппаратный watchdog ребутящий систему в случае зависания) и останавливать работу если не может.

Всё это portage делает.

>А если автоматика впадает в ступор даже от банальной необходимости использовать gcc-3 для сборки qemu, экспортировать базу ldap и импортировать обратно, не умеет перезапускать обновленные сервисы это означает, что автоматизация низкая.

Это означает, что Вы не поняли зачем это сделано именно так.

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

Если Вы немного подумаете, то найдёте плюсы и минусы у каждого элемента пары, а также поймёте почему используют и то и другое.

>0 раз комфортнее.

А мне нет.

>Обычно после make oldconfig я делаю make xconfig.

А можно чуток подумать, и сперва решить нужна Вам именно эта версия ядра или нет, и только потом прибегать к таким радикальным шагам ;)

>Вот и меня ручной труд там где с ним справляется автоматика и неоьходимость уделять системе повышенное внимание не устроила. Поэтому и была произведена замена Gentoo на более автоматизированный инструмент.

И опять не понятно, при чём тут gentoo. Я уже давно понял, что Вам она не подходит, меня в этом убеждать не надо. С генты я точно в ближайшее время не уйду. Что ещё сказать-то хотите?

>Ваша версия.

Почитать документы на gentoo.org.

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

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

>При основании проекта, возможно тогда таких еще и не было.

Посмотрите дату последнего релиза (0.76)

>Вопрос явно не ко мне, а к авторам.

Т.е. десятилетний стаж не позволяет Вам подумать немного над этой проблемой? Хорошо. Мой трёхлетний, подсказывает, что если на задачу наложены серьёзные ограничения, то решается она проще и быстрее общей.

>Оптимизация в работе gnomebaker от использования liboil тоже есть. Зачем тогда было возмущаться? :) Приведенный в топике пример показывает что польза от сборки с -mfpmath=sse есть, собранный с разными флагами nbench показывает что ее нет.

Какая интересная интерпретация результатов! Мне это напомнило анекдот, где экспериментальным путём выяснили, что таракан слышит ногами...

>Подсказка: тестовую систему можно развернуть в chroot.

Да Вы что! А вне этого окружения запустить просмотр какого-нибудь фильма. Для пущей точности! Нет уж, если подходить к этому вопросу серьёзно, то нужен именно стенд.

>Ставим процессор с архитектурой AMD64, бинарный AMD64 дистрибутив и не паримся.

Значит не ясно.

>А этого никто не знает, разве что сами создатели процессоров. Но оно было заметно ещё во времена athlon vs p4. В синтетике p4 обгонял атлона почти вдвое, в реальных приложениях атлон был зачастую даже быстрее чем p4.

А подумать?

>Я в дебиане могу иметь две версии gcc, могу иметь qemu вообще без установки gcc, получается в дебиане вариантов "свободы" больше?

А Вы не слышали про слоты и бинарные пакеты?

>То есть получается, с этими же патчами можно собрать опенофис где угодно?

А Вы попробуйте!

>Впервые слышу, что Генту приносит какую-то пользу. Можно ссылку, подтверждающую это?

А можно ссылку подтверждающую помощь от дебиана?

Хотел тебе ответить но уже опередили:)

Генто действительно очень много патчей возвращает разработчикам програм, и в подавляющем большинстве случаев разработчики радо принимают патчи и пожелания. А как посчитать чтобы ссылку дать? Можно было бы както вытянуть статистику з портадж сколько Mb патчей в files/*.patch ложится и удаляется. Потом считать что если патч с портадж удалили значить он учтён разработчиками.

>производительность этого поделия оставляла желать лучшего.

Смешно даже сравнивать производительность оптимизированой Генты с тормозами Дебиана.

>>Корректировать ошибку если может с ней справиться(примеры: CRC,ECC,система стабилизации ESP,аппаратный watchdog ребутящий систему в случае зависания) и останавливать работу если не может.

>Всё это portage делает.

Не делает. И были приведены примеры когда emerge встает колом на детских "проблемах". Свежий прикол:

[blocks B ] <kde-base/kdebase-3.5.7-r6 (is blocking kde-base/kdelibs-4.0.0)

Автоматика блин.

> Это означает, что Вы не поняли зачем это сделано именно так.

Мне неинтересны оправдания. При апгрейде Debian с sarge на etch базы mysql и ldap мигрировали. Генто перенести базу ldap ниасиливает - все ручками. Я вижу что автоматизация в Debian в данном случае существенно лучше. Тоже самое и с обновлением служб.

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

> Если Вы немного подумаете, то найдёте плюсы и минусы у каждого элемента пары, а также поймёте почему используют и то и другое.

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

> А можно чуток подумать, и сперва решить нужна Вам именно эта версия ядра или нет, и только потом прибегать к таким радикальным шагам ;)

Нужна. Предлагаете на дырявом ядре сидеть? Меня бы устроила и старая версия, но с фиксами безопасности. При этом ядро и сторонние модули(modules-rebuilde) все равно придется пересобирать, даже если на другой системе генерик ядро устраивает на 100%.

> Я уже давно понял, что Вам она не подходит, меня в этом убеждать не надо. С генты я точно в ближайшее время не уйду. Что ещё сказать-то хотите?

Я вас и не заставляю переходить.

>Значит handbook бегло просмотрели, другими инструменты для автоматической правки конфигов не интересовались...

Думаете, за 4 года эксплуатации генты можно было упустить из виду etc-update? Ну и где там автоматическая миграция? Эта штука вываливает список измененных конфигов и список действий - заменить/оставить/смержить. Если была бы автоматизация, то она без единого вопроса обновила бы конфиги скриптом миграции.

> Так как мне в Убунте без ручного патчения ядра сделать, чтобы atop (который там есть) поддерживал мониторинг дисковой и сетевой активности?

aptitude install kernel-patch-atopcnt и далее проедура сборка своего ядра с помощью make-kpkg. Да, это один из тех случаев, когда требуется глубокая модификация ядра, установкой модулей не обойтись, поэтому необходимость сборки собственного ядра обоснована.

+ kernel-patch-atopacct

>Не делает. И были приведены примеры когда emerge встает колом на детских "проблемах".

Некоторым кажется, что если программа не может считать с моска что они хотят, то она не автоматизирована.

>Свежий прикол:

>[blocks B ] <kde-base/kdebase-3.5.7-r6 (is blocking kde-base/kdelibs-4.0.0)

>Автоматика блин.

Т.е. ринулись размаскировать даже не читая gentoo.org? Ну ССЗБ!

>Мне неинтересны оправдания.

Аналогично!

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

Автоматика не узнает человека, она узнает только ключ. А такая, которая узнает ещё не создана, а если будет создана, то проще будет бабушку поставить... Именно поэтому ставят автоматику и бабушку: автоматика проверяет ключ, а бабушка узнаёт человека.

>Меня бы устроила и старая версия, но с фиксами безопасности.

А Вы не слышали, что теперь stable - 2.6.16-59? И кстати в портежах оно присутствует?

>Ну и где там автоматическая миграция?

А это специальное напоминание: "стой! Остановись - подумай о смерти!"

> Посмотрите дату последнего релиза (0.76)

> Т.е. десятилетний стаж не позволяет Вам подумать немного над этой проблемой? Хорошо. Мой трёхлетний, подсказывает, что если на задачу наложены серьёзные ограничения, то решается она проще и быстрее общей.

То вы заявляете, что вам не нужны догадки, то требуете объяснение почему авторы поступили именно так, то сами высказываете свои собственные домыслы насчет того почему авторы поступили именно так, а не иначе. Вас не понять. А предполагаемая причина не дает ответа зачем авторы городили свои костыли, вместо того, чтобы использовать специализированный компонент.

> Какая интересная интерпретация результатов! Мне это напомнило анекдот, где экспериментальным путём выяснили, что таракан слышит ногами...

По вашим результатам разницы между -march=i486 и -march=pentium4 не видно, 10%-ного прироста от -mfpmath по floating point index также не наблюдается. Рез-ты отличаются в интервале от 1 до 5%. Но даже если на вымирающей архитектуре x86 и наблюдался прирост по скорости оп-ций с плавающей точкой на тестовой сишной сферической программке в вакууме, то на AMD64 толку от генты вообще никакого.

> Значит не ясно.

Совершенно ясно, что компилировать из исходников, тем более на AMD64, нет резона и ставить старые медленные 32-битные x86 камни под мегавычислительные задачи смысла. А в свете использования вами 64-битной архитектуры, также совершенно непонятны причины которые побудили вас собирать liba52 с -mfpmath=sse, когда -march=amd64 автоматически подразумевает и -mfpmath=sse.

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

>Совершенно ясно, что компилировать из исходников, тем более на AMD64, нет резона............

Здесь уже объясняли анонимусу (наверно другому) что оптимизация в Генте это: 1. Оптимизация программного обеспечения под свои нужды. 2. Оптимизация программного кода под аппаратное обеспечение. Если тебе надо иметь определённые программы с нужным функционалом и взаимосвязями то всё равно придётся их собирать и при этом целесообразно за одно оптимизировать их и под процессор, а проще всего это сделать в Генте!

>Решил поспорить с оставшимися гентушниками насчет ниши генты, насчет того для чего она лучше, насчет несерьезности из-за отсутствия LSB совместимости

Я как бы немного не вкурсе, но где в lsb записано, что загрузка должна ити по init 2 и будут ли стартовать иксы или нет, должно определятся наличием или отсутствием kdm/gdm/xdm etc ?

P.S. Это так в Дебиане сделано, если кто не знает.

> Вообще ИМХО лучше генту или LFS в качестве тренажера позволяющего глубоко познать систему от и до врядли что-то еще есть.

>Для этого - Slackware. А гентуу и LFS в качестве "тренажёра" это искусственное усложнение задачи, причём не дающее в плане "тренировки" ничего.

+1 Но, согласитесь, Гента немного не для этих целей разрабатывалась. Впрочем, как и Slackware.

>в чём нишевость Slackware по сравнению с Debian?

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

А в чём заключается это "серьёзное массовое использование" (именно "Серьёзное")? Да и не забывайте, что Слака построена по принцыпу конструктора, что позволяет относительно легко создавать небольшие (или даже большие ;)) "дистрибутивы" для личного использования для специфических задач.

>1) Это слова Линуса о том, зачем он начал свой проект, а следующие его слова были - цель линукса - world domination. И что?

А может не будем цитировать Линуса почём зря? Я конечно понимаю, что он для всех нас авторитет, но всё же это не Ленин/Маркс и GPL не требует в каждом посте вставлять его слова, подтверждающие верность автора принципам сообщества.

>2) Уже сто раз было расжевано здесь, что дебиан не привязывается к линуксу, есть наработки и для других ядер, просто линукс самое продвинутое из открытых на данный момент ядро.

Ну вот когда Debian/BSD добъёт Фряху, вот тогда о нём и поговорим, а пока рассматриваем Линукс как "самое продвинутое из открытых на данный момент ядро".

> +1 Но, согласитесь, Гента немного не для этих целей разрабатывалась. Впрочем, как и Slackware.

Не для этих, да. Гента - сборка всего и вся из исходников, слака - vanilla-софт и ядро. Но по факту больше их применять некуда.

Ну слаку ещё хорошо на роутеры, файлопомойки и прочую сетевую мелочь, а вот гентуу туда ставить бессмысленно - найти комп который не потянет тот же NAT на 100 компов сейчас весьма трудно, т.е. оптимизаторство идёт лесом. А ждать сутки пока оно соберётся, когда слака под FTP и роутер ставится и настраивается полностью за 20 минут...

Господа! Может хватит сраться чей дистрибутив супер-мега-пупер офигительный... Ведь все зависит от человека... каждому свое.

Если кто не заметил - ветка про желание вернуться DR. Если кому не нравится лично он - отпишитесь. Если есть неприязнь конкретно к дистрибутиву зачем тогда его ковырять и пытаться обсерить чисто потому что "дистр меня не устраивает". Кому нужна gentoo - тот и будет с ней работать. остальные идут лесом...

> для серверов хочу selinux & grsecurity & PAX

Для тех, кто все еще кипятит:

anonymous@lor-tty3:~/tmp$ gcc vuln-stack.c -o vuln-stack
anonymous@lor-tty3:~/tmp$ ./vuln-stack `perl -e "print 'A'x100"`
*** stack smashing detected ***: ./vuln-stack terminated
Aborted
anonymous@lor-tty3:~/tmp$ objdump -T vuln-stack|grep stack
vuln-stack:     file format elf32-i386
00000000      DF *UND*  00000046  GLIBC_2.4   __stack_chk_fail
$ objdump -T /usr/sbin/apache2 |grep stack
00000000      DF *UND*  00000046  GLIBC_2.4   __stack_chk_fail
0809ba90 g    DO .data  00000004  Base        ap_hack_apr_threadattr_stacksize_set
08063718      DF *UND*  0000002d              apr_threadattr_stacksize_set
anonymous@lor-tty3:~/tmp$ objdump -T /usr/lib/firefox/firefox-bin |grep stack
00000000      DF *UND*  00000046  GLIBC_2.4   __stack_chk_fail

anonymous@lor-tty3:~/tmp$ gcc vuln-heap.c -o vuln-heap
anonymous@lor-tty3:~/tmp$ ./vuln-heap `perl -e "print 'A'x1024"`
DEBUG: chunk1=0x804a008(size 130), chunk2=0x804a090(size 30)
(chunk2-chunk1)=136
Performing strcpy()
*** glibc detected *** ./vuln-heap: free(): invalid next size (normal): 0x0804a008 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7eb4d65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7eb8800]
./vuln-heap[0x80484f7]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7e61050]
./vuln-heap[0x80483e1]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:13 2965996    /home/anonymous/tmp/vuln-heap
08049000-0804a000 rw-p 00000000 08:13 2965996    /home/anonymous/tmp/vuln-heap
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
b7d00000-b7d21000 rw-p b7d00000 00:00 0
b7d21000-b7e00000 ---p b7d21000 00:00 0
b7e4a000-b7e4b000 rw-p b7e4a000 00:00 0
b7e4b000-b7f8f000 r-xp 00000000 08:13 835756     /lib/tls/i686/cmov/libc-2.6.1.so
b7f8f000-b7f90000 r--p 00143000 08:13 835756     /lib/tls/i686/cmov/libc-2.6.1.so
b7f90000-b7f92000 rw-p 00144000 08:13 835756     /lib/tls/i686/cmov/libc-2.6.1.so
b7f92000-b7f95000 rw-p b7f92000 00:00 0
b7fa6000-b7fb0000 r-xp 00000000 08:13 838445     /lib/libgcc_s.so.1
b7fb0000-b7fb1000 rw-p 0000a000 08:13 838445     /lib/libgcc_s.so.1
b7fb1000-b7fb4000 rw-p b7fb1000 00:00 0
b7fb4000-b7fce000 r-xp 00000000 08:13 835668     /lib/ld-2.6.1.so
b7fce000-b7fd0000 rw-p 00019000 08:13 835668     /lib/ld-2.6.1.so
bf981000-bf996000 rw-p bf981000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
Aborted
anonymous@lor-tty3:~/tmp$ gcc -v
Используются внутренние спецификации.
Целевая архитектура: i486-linux-gnu
Параметры конфигурации: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Модель многопотоковости: posix
gcc версия 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

А это в ядре: http://lkml.org/lkml/2006/7/28/161

>Если кто не заметил - ветка про желание вернуться DR.

Первый день на Лоре? ;) Покажите хоть одну ветку за последние несколько лет (с количевством сообщений где-то за сотню) где в названии присутствуют такие мощные флеймовызывающие заклинания как Slackware или Gentoo, учасники дисскуссии в которой помнят как она назывется.

> Покажите хоть одну ветку за последние несколько лет (с количевством сообщений где-то за сотню) где в названии присутствуют такие мощные флеймовызывающие заклинания как Slackware или Gentoo, учасники дисскуссии в которой помнят как она назывется.

Да, кстати, что характерно, почти 1500 постов набили, а тема не скатилась к матерщине, гомосексуализму и разборкам между "красноглазыми" и "пролетариатом".

> Некоторым кажется, что если программа не может считать с моска что они хотят, то она не автоматизирована.

Бред. Смена gcc которую требует ебилд, перезапуск обновленной службы, миграция конфига(мантейнер имеет полные сведения что изменилось) или миграция базы на новую версию не требуют считывания из мозга.

> Т.е. ринулись размаскировать даже не читая gentoo.org? Ну ССЗБ!

Это человек захотел поставить KDE4, который вышел. Гента как обычно пришла в смятение и предлагает остаться без kdelibs3. Ха-ха-ха. В убунте почему-то kdelibs3 и 4 могут стоять параллельно. Снова косяк.

$ apt-get install kdelibs5 Чтение списков пакетов... Готово Построение дерева зависимостей Reading state information... Готово Будут установлены следующие дополнительные пакеты: kde4libs-bin kdelibs5-data libphonon4 libqt4-qt3support libqt4-sql librasqal0 librdf0 libsoprano4 libsqlite0 Предлагаемые пакеты: libqt4-dev Рекомендуемые пакеты: redland-utils НОВЫЕ пакеты, которые будут установлены: kde4libs-bin kdelibs5 kdelibs5-data libphonon4 libqt4-qt3support libqt4-sql librasqal0 librdf0 libsoprano4 libsqlite0

> Аналогично!

Факт в том, что на мегагибкой убунте KDE4 приводит к проблемам.

> Автоматика не узнает человека, она узнает только ключ.

Есть биометрия. А владелец несет ответственность за сохраннось электронного ключа.

> А такая, которая узнает ещё не создана, а если будет создана, то проще будет бабушку поставить...

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

> А Вы не слышали, что теперь stable - 2.6.16-59? И кстати в портежах оно присутствует?

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

> А это специальное напоминание: "стой! Остановись - подумай о смерти!"

Все мы смертны. У серверов есть бэкап. При обновлении openldap в STABLE версия не меняется так что проблем не будет. При переходе на следующий релиз системы раз в N лет можно и поприсутствовать, хотя по причине, что разработчики Debian делают качественную систему и тестируют скрипты миграции проблем обычно не возникает. Если все же скрипт миграции вывалился с ошибкой то старый LDIF ведь можно и оставить, да и миграцию можно проводить во временном каталоге и когда все получилось замещать основную базу. Вариантов масса. Но мантейнерам гентуу, видимо, не до таких мелочей.

s/убунте/генте/ заговорился )

>Да, кстати, что характерно, почти 1500 постов набили, а тема не скатилась к матерщине, гомосексуализму и разборкам между "красноглазыми" и "пролетариатом".

Просто паралельно сущевствовала тема о гноме в Slackware.;) Просто для местных ИТ-проповедников легче весты споры на тему "Зависимости рулят" так как man apt-get прочитать проще чем man gcc $)

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

У Вас похоже проблемы с памятью. Перечитайте ещё раз последние 100 комментариев.

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

Как раз она-то и даёт. fftw - решает проблему Фурье-преобразования с как можно более общих позиций. В этой библиотеке есть функции для анализа практически любых данных. Что качается liba52 - там этого не надо. Заранее известно какого типа входные данные, их объёмы, и их приблизительные диапазоны изменения. Именно это позволяет писать свой простенький, но довольно эффективный костыль. Так что это именно тот самый пример, почему так мало программ используют liboil, и зачем пишутся свои костыли, не смотря на очень хорошо оптимизированные общие библиотеки.

>По вашим результатам разницы между -march=i486 и -march=pentium4 не видно, 10%-ного прироста от -mfpmath по floating point index также не наблюдается.

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

>Совершенно ясно,

Т.е. кроме опимизаций под инструкции, Вы никаких других оптимизаций не признаёте.

>также совершенно непонятны причины которые побудили вас собирать liba52 с -mfpmath=sse, когда -march=amd64 автоматически подразумевает и -mfpmath=sse.

Этой причиной были Вы, дорогой Анонимный Теоретик! Причём я собирал liba52 с различными вариантами -march

>Смена gcc которую требует ебилд, перезапуск обновленной службы, миграция конфига(мантейнер имеет полные сведения что изменилось) или миграция базы на новую версию не требуют считывания из мозга.

Если Вы не поняли зачем и почему так сделано, то не надо тут это выставлять на показ.

>Это человек захотел поставить KDE4, который вышел.

Ну так значит тот человек ССЗБ. Если бы он почитал документацию по миграции (ссылка на которую даже в /portage/profiles/package.mask находиться) то у него бы не возникло таких проблем.

>Факт в том, что на мегагибкой убунте KDE4 приводит к проблемам.

Знаете, а мне это безразлично.

>Есть биометрия. А владелец несет ответственность за сохраннось электронного ключа.

Да Вы что! И эта биометрия спросит у Вас: ну как дела? Что-то Вас давно не было видно! А как там погода на улице, снег всё ещё идёт? А электронный ключ можно и скопировать и украсть...

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

Вашими устами, да мёд бы пить!

>Ну кроме ядра есть еще и другие пакеты. А хочется поставить, настроить, забыть...

Так Вы же про ядро спрашивали! Вас что-то никак не понять! Кто Вам мешает использовать stable ядро? До тех пор, пока его будет поддерживать Линус, оно будет в портеже

>Если все же скрипт миграции вывалился с ошибкой то старый LDIF ведь можно и оставить, да и миграцию можно проводить во временном каталоге и когда все получилось замещать основную базу. Вариантов масса.

И один из них (на который и рассчитывают разработчики gentoo) - вдумчивое чтение замечаний, рекомендаций и указаний по миграции, чтобы потом всё сделать просто и получить именно то что Вы хотите от данной миграции на более свежий софт. Причём желательно всё это делать на специальном сборочном сервере, а на рабочий только залить бинарные пакеты.

Вообще я за Gentoo и всегда за нее буду!!! Не раз выснялось что если у тебя не кривые руки то просто она быстрее. Да, компиляция - долго и иногда при определнных обстоятельствах требует ручного вмешательства - но за то результат налицо. Сам это выявил когда сравнил производительность Ubuntu(производное от дебиана) и Gentoo на одинаковых машинах в Tremulous, например на Gentoo fps редко опускалась до 90 а Ubuntu - 60max; в OOO - загрузка его собираемой версии шла секунды на 3-4 быстрее чем Ubuntu

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

Да в нових gcc-4 и glibc кое какая защита от переполнения буфера есть. Но как на счёт гибкой защиты памяти? Есть програмулина paxtest протестируй Убунту ею...

Я считаю что правельным путём есть именно grsec+pax он даёт много больше чем простая защита от переполнения буфера.

./vuln-stack
grsec: signal 11 sent to /home/ebuild/test/vuln-stack[vuln-stack:22028] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /home/ebuild/test/vuln-stack[vuln-stack:22028] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001

*** stack smashing detected ***: vuln-stack - terminated
vuln-stack: stack smashing attack in function main - terminated
Report to http://bugs.gentoo.org/
Killed

vuln-stack:     file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000000  w   D  *UND*  00000000              __gmon_start__
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
00000000      DO *UND*  00000004  GLIBC_2.3.2 __guard
00000000      DF *UND*  000001b7  GLIBC_2.0   __libc_start_main
00000000      DF *UND*  000009d5  GLIBC_2.3.2 __stack_smash_handler
00000000      DF *UND*  00000023  GLIBC_2.0   strcpy
00000000  w   DF *UND*  000000e7  GLIBC_2.1.3 __cxa_finalize
00002010 g    D  *ABS*  00000000  Base        _end
0000200c g    D  *ABS*  00000000  Base        _edata
00000710 g    DO .rodata        00000004  Base        _IO_stdin_used
0000200c g    D  *ABS*  00000000  Base        __bss_start
000005d8 g    DF .text  0000007c  Base        main

./vuln-heap
Segmentation fault
grsec: signal 11 sent to /home/ebuild/test/vuln-heap[vuln-heap:22029] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /home/ebuild/test/vuln-heap[vuln-heap:22029] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001

2.6.22-hardened-r6

libc-2.6.1

Configured with: /var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libgcj --with-arch=i686 --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)

Да в новых gcc-4 и glibc кое какая защита от переполнения буфера есть.
Но как на счёт гибкой защиты памяти?
Есть програмулина paxtest протестируй Убунту ею...

Я считаю что правильным путём есть именно grsec+pax
он даёт много больше чем простая защита от переполнения буфера.

./vuln-stack
grsec: signal 11 sent to /home/ebuild/test/vuln-stack[vuln-stack:22028] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /home/ebuild/test/vuln-stack[vuln-stack:22028] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001

*** stack smashing detected ***: vuln-stack - terminated
vuln-stack: stack smashing attack in function main - terminated
Report to http://bugs.gentoo.org/
Killed

vuln-stack:     file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000000  w   D  *UND*  00000000              __gmon_start__
00000000  w   D  *UND*  00000000              _Jv_RegisterClasses
00000000      DO *UND*  00000004  GLIBC_2.3.2 __guard
00000000      DF *UND*  000001b7  GLIBC_2.0   __libc_start_main
00000000      DF *UND*  000009d5  GLIBC_2.3.2 __stack_smash_handler
00000000      DF *UND*  00000023  GLIBC_2.0   strcpy
00000000  w   DF *UND*  000000e7  GLIBC_2.1.3 __cxa_finalize
00002010 g    D  *ABS*  00000000  Base        _end
0000200c g    D  *ABS*  00000000  Base        _edata
00000710 g    DO .rodata        00000004  Base        _IO_stdin_used
0000200c g    D  *ABS*  00000000  Base        __bss_start
000005d8 g    DF .text  0000007c  Base        main

./vuln-heap
Segmentation fault
grsec: signal 11 sent to /home/ebuild/test/vuln-heap[vuln-heap:22029] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001
grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /home/ebuild/test/vuln-heap[vuln-heap:22029] uid/euid:1001/1001 gid/egid:1001/1001, parent /mnt/livecd/bin/bash[bash:28530] uid/euid:1001/1001 gid/egid:1001/1001

2.6.22-hardened-r6

libc-2.6.1

Configured with: /var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libgcj --with-arch=i686 --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)

>>производительность этого поделия оставляла желать лучшего.

>Смешно даже сравнивать производительность оптимизированой Генты с тормозами Дебиана.

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

>Слака построена по принцыпу конструктора, что позволяет относительно легко создавать небольшие (или даже большие ;)) "дистрибутивы" для личного использования для специфических задач.

Слака позволяет "создавать" "дистрибутив" из ядра и coreutils, на что-то большее она не способна. Если че, то debian-netinstall для цели "создавать дистрибутив для специфической задачи" подходит гораздо лучше.

>А может не будем цитировать Линуса почём зря?

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

>Ну вот когда Debian/BSD добъёт Фряху, вот тогда о нём и поговорим, а пока рассматриваем Линукс как "самое продвинутое из открытых на данный момент ядро".

Млять, ядро - это десяток из 18000 пакетов, отвечающих требованиям dfsg, debian policy, прошедших три стадии тестирования и т.д. Значения этих и многих других умных слов ты можешь посмотреть на официальном сайте, если умеешь читать. Сомневаюсь конечно что гентушнеги умеют что-то, кроме как вбивать команды для инсталляции из хендбука.

Да если уже будешь http://pax.grsecurity.net/paxtest-0.9.7-pre4.tar.gz гонять попробуй и и этот для grsec: http://cvsweb.grsecurity.net/index.cgi/regression/

>Ага, именно смешно. Свои измерения я уже приводил, и не только я - почитайте тред.

Ну давай что то конкретное замеряем, только надо оговорить условия: отключаем selinux, grsec (а они на x86 немного тянут) так же стоит оговорить другие условия (версии ядра хедеров, библиотек, файловую систему) и можно что то потестить если так хочется...

>Сказки про "высоконагруженные сервера" можете рассказывать где-то еще.

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

>Слака позволяет "создавать" "дистрибутив" из ядра и coreutils, на что-то большее она не способна.

Вам удалось с помощью дебиана создать "дистрибутив" без ядра и coreutils и он оеазался работоспособным?

>Если че, то debian-netinstall для цели "создавать дистрибутив для специфической задачи" подходит гораздо лучше.

Чем? Тем что в него нихрена не входит (40 Мб) или входит "совсем базовая система" (180 Мб), а всё остальное из Нета тянуть? А получится потом что? Тот же Дебиан (зависимости, зависимости)? Если Слака ориентирована на "ручки", то в этом случае это очень помогает. Всё же в Слакваре разнообраные конфиги править легче.

>Ну вот когда Debian/BSD добъёт Фряху, вот тогда о нём и поговорим, а пока рассматриваем Линукс как "самое продвинутое из открытых на данный момент ядро".

>Млять, ядро - это десяток из 18000 пакетов, отвечающих требованиям dfsg, debian policy, прошедших три стадии тестирования и т.д. Значения этих и многих других умных слов ты можешь посмотреть на официальном сайте, если умеешь читать. Сомневаюсь конечно что гентушнеги умеют что-то, кроме как вбивать команды для инсталляции из хендбука.

А __вдумчиво__ почитать предложение не судьба? Привычка реагировать на любое не восхищённое упоминание о Debian'е аки бык на красную тряпку выдаёт в вас фанатика. Шифруётесь более качевственно ;)

>Ну вот когда Debian/BSD добъёт Фряху, вот тогда о нём и поговорим, а пока рассматриваем Линукс как "самое продвинутое из открытых на данный момент ядро".

Перевожу смысл предложения с русского на красноглазый: "Вот когда доля Дебиана на ядре bsd станет настолько сущевственной, что начнёт серёзно влиять на развитее этого самого ядра (например, дебианщики-bsd-ядерные начнут нападать в форумах на фряшников и обзывать их красноглазыми ибо порты, а не АРТ), вот тогда эти альтернативные ядра можно будет рассматривать серьёзно. А пока это только просто "понты"", не более.

P.S. А вообще больно смотреть на Дебиан. Хороший дистрибутив с неплохой идеологией попал в рабство к своему пакетному менеджеру.

>А может не будем цитировать Линуса почём зря?

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

Не знаю, кто всё это начал, но я заметил Вас за множественным повторением мантры "Есть только Debian -- всё остальное -- Just for Fun!!!"

> Да в новых gcc-4 и glibc кое какая защита от переполнения буфера есть.

В libc защита от эксплуатации переполнение на куче - с версии glibc-2.3. В ядре рандомизация адресов ASLR, не позволяющая пробрутать адрес возврата(потому что адреса от запуска к запуску изменяются, а после неудачной эксплутации программа падает) - с 2.6.12.

> Но как на счёт гибкой защиты памяти?

В 64-битных процессорах исправили недоделку x86 введя бит NX. В недоделанном x86 на уровне страниц был единственный бит, который отвечал и за чтение данных и за выполнение кода. Костыль PAX пока еще нужен для исправления проблемы в генах x86, на современном 64-битном массовом железе необходимость в нем сомнительна.

> Есть програмулина paxtest протестируй Убунту ею...

Знаю что будет. Но речь не о сферическом коне в вакууме и не о возможности запустить код на стеке или куче, а о борьбе с реальными эксплоитами. Для того, чтобы запуститься нужно угадать плавающий адрес возврата и пройти проверки на переполнение. Реальный эксплоит на той же убунте, которая от и до собрана с проверками на переполнение стека(к сожалению в дебе этого пока нет), с прыгающими базами кода, кучи и стека - ASLR, защитой от эксплуатации free() при переполнении кучи, испытает мягко говоря некоторые трудности. При желании можно настроить apparmor или selinux, ограничив полномочия взлоумышленника, который сможет пройти все уровни защиты, мизерным набором полномочий, например в случае bind - никакого шелла, никакого создания или исполнения файлов, никакого доступа к файлам к которым демон ни при каких условиях не должен иметь доступа, никакого биндинга на порты отличные от 53. Мне неизвестны живые эксплоиты, которые смогли бы обойти хотя бы ASLR, не говоря уже про -fstack-protector или защиту в libc.

> ./vuln-stack grsec: signal 11 sent ./vuln-heap Segmentation fault

Эффект тот же самый, только не на уровне программ собранных с -fstack-protector и libc, а на уровне ядра. Проверки добавляемые -fstack-protector потому, что блокируют метод выполнения кода на неисполнимым стеке - ret-in-libc, против чего PAX бессилен. Суть метода проста: затираем при переполнении адрес возврата на стеке адресом нужной функции в libc, например, system(), набиваем стек стройкой-аргументом, например "rm -rf /", и ее адресом перед адресом возврата и при возврате из уязвимой процедуры по ret будет осуществлен переход на system("rm -rf /"), чему не сможет помешать никакая защиты памяти. ASLR усложняет задачу, заставив угадывать плавающий адрес system(), но можно обойти гору через COMPAT_VDSO по фиксированнуому адресу(можно включить рандомизацию адреса отображения VDSO в адресное пространство процесса параметром ядра vdso=1). А проверка оставленная -fstack-protector проверит не произошло ли перетирание 8-байтовой защитной границы(генерируется случайный заполнитель) перед адресом возврата и если нарушение границы произошло, то аварийно завершит работу атакуемой программы.

Ужос. Извиняюсь за писанину в спешке.

s/эксплуатации переполнение/эксплуатации переполнения/

s/взлоумышленника/злоумышленника/

s/стройкой/строкой/

s/Проверки добавляемые -fstack-protector/Проверки добавляемые -fstack-protector надежнее/

> Да если уже будешь http://pax.grsecurity.net/paxtest-0.9.7-pre4.tar.gz гонять попробуй и и этот для grsec: http://cvsweb.grsecurity.net/index.cgi/regression/

Лучший усилитель чрута - selinux или виртуализованный изолированный сервер. Необходимость GRsex RSBAC при наличии ненстримового SELinux из коробки сомнительна. :)

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

>У Вас похоже проблемы с памятью. Перечитайте ещё раз последние 100 комментариев.

Разве этого не было? Или сами авторы где-то указали причины использования своих костылей вместо fftw?

> Как раз она-то и даёт. fftw - решает проблему Фурье-преобразования с как можно более общих позиций. В этой библиотеке есть функции для анализа практически любых данных. Что качается liba52 - там этого не надо. Заранее известно какого типа входные данные, их объёмы, и их приблизительные диапазоны изменения.

libc - решает проблему взаимодействия с системой с как можно более общих позиций. В конкретной программе этого не надо. Заранее известно какого типа системные вызовы нужны и на какой архитектуре будет программа работать. Лишние неиспользуемые процедуры отнимают место в кеше и на диске, написаны неоптимально без использования SIMD и без учета особенности АЛУ, векторных блоков SSE/MMX, кешей и конвейеров, системные вызовые осуществляются через лишнюю прослойку VDSO, накладные расходы на динамическую линковку. Надо срочно отказаться от динамического связывания и использования libc, написав свой велосипед на ассемблере наиболее эффективно(неэффективному gcc нельзя доверять) и вызывать систему напрямую syscall/sysenterjv а не через какие-то там DSO! Это и есть красноглазие.

>>По вашим результатам разницы между -march=i486 и -march=pentium4 не видно, 10%-ного прироста от -mfpmath по floating point index также не наблюдается.

> Может быть Вы дадите мастер-класс по анализу результатов бенчмарков?

Floating point и Integer Index практически один в один, разница - 1% и 4,89%.

> Т.е. кроме опимизаций под инструкции, Вы никаких других оптимизаций не признаёте.

Признаю. Размеры и архитектура кеша, особенности блоков АЛУ, BPU и т.д. У вас есть информация насколько gcc эффективно оптимизирует под этим параметры, где использует размеры L1/L2 и как отличает, например, celeron от pentium 4 при -march=pentium4? Предлагаете писать весь код на ассемблере под целерон, под пентиум4, под пентиум4-у-которого-битового-операция-сдвига-тормознее-операции-сложения и т.д.?

>>также совершенно непонятны причины которые побудили вас собирать liba52 с -mfpmath=sse, когда -march=amd64 автоматически подразумевает и -mfpmath=sse.

>Этой причиной были Вы, дорогой Анонимный Теоретик! Причём я собирал liba52 с различными вариантами -march

Хорошо. Но ответ в чем польза от используемой вами генты на AMD64 в плане оптимизации под процессор вы так и не ответили. Видимо, тот факт, что бинарный дистрибутив оптимизирован под AMD64 искаропки с -mfpmath=sse поставил вас в тупик...

>>Смена gcc которую требует ебилд, перезапуск обновленной службы, миграция конфига(мантейнер имеет полные сведения что изменилось) или миграция базы на новую версию не требуют считывания из мозга.

>Если Вы не поняли зачем и почему так сделано, то не надо тут это выставлять на показ.

Как это не понял? Понял. Мантейнеры генты свалили свою работу на пользователей.

>>Факт в том, что на мегагибкой убунте KDE4 приводит к проблемам.

>Знаете, а мне это безразлично.

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

>>Есть биометрия. А владелец несет ответственность за сохраннось электронного ключа.

>Да Вы что! И эта биометрия спросит у Вас: ну как дела? Что-то Вас давно не было видно! А как там погода на улице, снег всё ещё идёт? А электронный ключ можно и скопировать и украсть...

А бабушку или охранника можно стукнуть по голове и связать. Или охранник-раздолбай может проспать ограбление.

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

>Вашими устами, да мёд бы пить!

У нас СКУДы стоят в трех зданиях. Поток один человек в две секунды - нормальная ситуация. А когда бываешь в недокомпаниях, где на входе нужно позвонить, а потом снимет трубочку бабушка, а затем что-то запишет в тетрадочку это напрягает.

>Так Вы же про ядро спрашивали! Вас что-то никак не понять! Кто Вам мешает использовать stable ядро?

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

> До тех пор, пока его будет поддерживать Линус, оно будет в портеже

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

> И один из них (на который и рассчитывают разработчики gentoo) - вдумчивое чтение замечаний, рекомендаций и указаний по миграции, чтобы потом всё сделать просто и получить именно то что Вы хотите от данной миграции на более свежий софт. Причём желательно всё это делать на специальном сборочном сервере, а на рабочий только залить бинарные пакеты.

Да? В таком случае чем вам не нравится сборка из исходников без зависимостей и USE-флагов? Там выбор опций конфигурирования не ограничен USE-флагами(USE-флаги это подмножество всех доступных опций конфигурирования), придется еще больше читать, еще больше думать чтобы все собралось и выполнять еще больше ручной работы! Ведь это же здорово?! :)

P.S. Послушав пользователей Gentoo я понял, что главное это вера в огромное ускорение от оптимизации без оценки насколько эффективен gcc, насколько большой прирост дает оптимизация на реальных задачах, сборка ценой дополнительных проблем, ценой часов складывающихся в сутки и месяци, ценой бесполезного прожигания электроэнергии, когда и без компиляции живется неплохо. Если в одной системе автоматика отлично справляется с миграцией конфигов, перезапуском сервисов, не требует никакой смены компиляторов, устанавливает KDE4 без сноса kdelibs3, а в генте не справляется, это не проблемы автоматизации, не не недостатки генты, это - идеология системы. Если поддержки LSB нет, значит он не нужен. Если собранных ядер и пакетов нет, значит они тоже не нужны и плевать^W безразлично, что большинство довольствуется собранными ядрами и пакетами - в генту идеология свободы: "Не нравится - свободен!" :)

>Послушав пользователей Gentoo я понял, что главное это вера в огромное ускорение от оптимизации

Ты явно не то что-то слушал. Или не тем органом.