Re: Перекомпиляция основных программ
> Н. Артём <Artiom14@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) --
> в общем случае не очень понятно.
Но, в общем-то, интересно... Раньше не слышал про это.
Reply to: