|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 21 Nov 2002 11:08:31
To : Aleksey Cheusov
Subject : Re: kernel compiling
--------------------------------------------------------------------------------
>>> Aleksey Cheusov wrote:
> >> А программисты для
> >> отладки пусть делают все, что хотят. Я не о них говорю. Тут Вагнер
> >> пример приводил, когда они с Чуприной сидя на одной машине имели
> >> разногласия в том, с какими опциями компилировать vim. Вот это я
> >> считаю ненормальным.
Там были *несовместимые* опции или просто шла речь, включать что-то или нет?
>> Считай как хочешь, но, ещё раз: на современном уровне развития IT эту
>> ненормальность побороть невозможно в принципе. Изобретёшь обходной вариант -
>> специально для тебя введут Hобелевскую премию за достижения в IT.
AC> Hе понимаю. Виндозным юзерам перекомпиляция в голову не приходит
AC> и работают же как то.
Действительно не понимаешь. Ты никогда не видел поставки чего-то в виде
standard, professional, enterprise и т.д. edition? Я уверен, что видел -
начиная с той же винды ;)
А по сути это полностью то же самое. Только параметры, которые можно
крутить, сгруппированы достаточно произвольным образом (исходя из средней
по больнице температуры, включая морг) в несколько типичных групп.
Что, однако, не мешает толстым клиентам заказывать специфические сборки
под себя, когда они считают это выгодным.
>> Фигнаны. Есть проблемы. Особенно если взаимодействие компонент системы с
>> окружением выполнено на препроцессоре (так эффективнее), и в функции не
>> заворачивается.
AC> Приложения, где нужна эффективность это не более 1%.
AC> 99% вполне себе обойдутся непрямыми вызовами функций и даже без всякой
AC> оптимизации. vim по-крайней мере не входит в список приложений нуждающихся
AC> в супероптимизации и его функциональность вполне можно было бы раскидать
AC> на кучу .so и "собирать" его перечислением тебе нужных.
Ага. Вот с таким подходом и получается мозилла, которая по 20 секунд грузится
и по 5 секунд поднимает окно написания письма в ответ на кнопку "Compose".
>> Это - правильный подход. Hо не всегда такая модульность возможна -
>> библиотек много, они могут встречаться в самых разных сочетаниях и дёргаться
>> из одного и того же модуля.
AC> Вот я и говорю, к проектированию надо подходить очень серьезно, поменьше
AC> "безжалосно рефакторить" и по-больше смотреть вперёд, а не под ноги.
"Безжалостно рефакторить" в XP относилось ко внутренним построениям и
интерфейсам.
То, что в open source его применяют к внешним, включая изменение ABI
на каждый чих из-за добавления поля в структуру - это уже проблема open source
народа и всяких Коксов, которые утверждают, что только так и нужно.
> >> Если я не ошибаюсь, dlopen будет грузить либу на новое место в памяти.
> >> Это, конечно, минус, но такой ли большой?
>> Про недостатки плагинов тут уже говорилось. БОльшая проблема в том, что
>> плагин всё равно надо собирать совместно с остальными частями софтины...
AC> Чтобы такого не было, надо всего лишь отделить интерфейсы от реализации
AC> и хорошо подумать над функциональностью каждого компонента.
Аксиомой является то, что нельзя заранее предугадать, что именно потребуется
на каждом этапе развития. И куда будет развитие востребовано, а куда - нет.
Hа всей Земле только один футуролог смог предсказать развитие цивилизации
с хорошей точностью, у остальных в 2000 году цвели яблони на Марсе.
А если залагаться на все варианты развития API с максимальной гибкостью -
протокол взаимодействия должен быть ASN.1+BER. С соответствующим оверхедом
и последствиями.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
