> Н. Артём <artio...@yandex.ru> writes: > > > Настоящие хардкорные гентушники говорят прежде всего о гибкости, > > > которую дает перекомпиляция (use-флаги, позволяющие для многих > > > пакетов включить/выключить использование каких-либо библиотек). > > Вряд ли это сильно влияет на скорость. Скорее, на объём занятого > > дискового пространства. Разве сейчас это кого-то сильно волнует на > > десктопе? > "Доктор, вы маньяк". Разумеется, ни то ни другое _обычно_ никого не > волнует. А вот избежать линковки с чем-нибудь падучим, или некрасивым, > или просто не вписывающимся в систему -- бывает желательно, точно так же > как выбрать из альтернативных реализаций какой-нибудь фичи менее > популярную. Хм... В сравнении со "стабильным Debian" это не является плюсом. Они и так пытаюся избежать использования чего-нибудь падучего. Отсюда вывод: выбрать другой дистр проще (ну, если имеется возможность выбора). Насчёт алтернативных... Тут про vim говорили. Не знаю. Сборок его - куча для Debian и vim-njx и gvim и прочее... Не знаю, что ткая за "фича", которая не влючена в сборки.
> Я вот (для домашних дебианов) emacs-snapshot с orebokech.com пересобираю > с athena вместо Gtk, и тут ни при чём ни скорость, ни дисковое > пространство, ни даже красота или кошерность -- просто у emacs-gtk есть > давний баг, из-за которой он не может открыть X connection после того, > как какой-нибудь из дисплеев один раз уронят. Это реально достает -- при > паттернах использования вроде "вытащил фрейм десктопного емакса на > нетбук, поработал, усыпил нетбук". Основной debian'овский emacs пока > собирают и под athena, но я не рассчитываю, что это будет долго > продолжаться. Однако, на данный момент... > Вот в генте решили "ничего не решать" за пользователя в > смысле таких взаимозаменяемых опций; подход имеет право на > существование. Ну, конечно имеет. Но никто не мешает сделать тоже самое, например в Debian? Если это единственная причина существования такого подхода - он неоправдан. Ведь есть и другие причины..? (а тестов так и нет) > [Правда, если бы гентообразные были сильнее распространены, это убило > бы последний стимул писать софт с динамической-плагинистой архитектурой > -- ну как vlc умеет все свои варианты UI без пересборки. А хотелось бы, > чтобы такого софта становилось со временем больше]. Ничего подобного. Плагины - совсе другой разговор. Их возможно включать и выключать динамически. Добавлять, убавлять и ещё чёрт знает чего делать. Причём, их может писать другой человек и выкладывать где угодно. Никакие USE флаги, портежи и прочее с ними не конкурируют. Просто разные задачи. > > > оказывается, что к *смыслу* изменений оно никакого отношения не имеет, а > > > просто какой-то кусок кода или данных расположился удачнее. Такой тип > > > ошибок почему-то редко кто подозревает; обычно присматриваются к > > > методике тестирования в части порядка запуска, или там набора исходных > > > данных -- при том, что основная составляющая ошибки может быть к моменту > > > запуска уже внесена. > > Но, тем не менее, что-то же этому способствовало? > Как правило, причина подобных вещей известна и её рано или поздно > начинает контролировать компилятор (или даже умеет контролировать -- при > определенных опциях -– но не в упомянутом мной случае). Проблема в том, > что если компилятор *не оптимизирует* какой-нибудь параметр (возьмем > простой пример: сборку с -O1, в которой не включается -falign-jumps и > подобное) -- этот параметр получается не "стабильно пессимизированный", > а непредсказуемый: сегодня у вас самый_главный_цикл попал на границы > кэшлайна, а завтра вдруг из-за совершенно нерелевантных причин не попадет. Какие причины? Включение какой-либо опции? > Такие засады можно побороть обработкой массива измерений, но (1) массив > должен быть не просто по куче запусков, а по куче пересборок, (2) способ > получения этой кучи пересборок должен "зашумлять" те факторы, влияние > которых мы хотим исключить. И вот как добиться выполнения пункта (2) -- > в общем случае не очень понятно. Но, в общем-то, интересно... Раньше не слышал про это. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/46891287326...@web2.yandex.ru
