|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 21 Nov 2002 21:04:42
To : Valentin Nechayev
Subject : Re: kernel compiling
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> writes:
> >>> Aleksey Cheusov wrote:
>
> > >> А программисты для отладки пусть делают все, что хотят. Я не о
> > >> них говорю. Тут Вагнер пример приводил, когда они с Чуприной
> > >> сидя на одной машине имели разногласия в том, с какими опциями
> > >> компилировать vim. Вот это я считаю ненормальным.
>
> Там были *несовместимые* опции или просто шла речь, включать что-то
> или нет?
Hе знаю. Он не уточнял.
>
> >> Считай как хочешь, но, ещё раз: на современном уровне развития
> >> IT эту ненормальность побороть невозможно в принципе. Изобретёшь
> >> обходной вариант - специально для тебя введут Hобелевскую премию
> >> за достижения в IT.
> AC> Hе понимаю. Виндозным юзерам перекомпиляция в голову не приходит
> AC> и работают же как то.
>
> Действительно не понимаешь. Ты никогда не видел поставки чего-то в
> виде standard, professional, enterprise и т.д. edition? Я уверен,
> что видел - начиная с той же винды ;)
Видел я только NT4, о которой ходили байки, что nt4 server и
workstation отличались только ключиком в registery, который она
тчательно охраняет каким-то сервисом. Я эту байку не проверял - не до
этого. Видел Delphi 1.0/2.0, которые были Standalone и Client/Server
edition. AFAIR они отличались разширенным набором компонент для работы
с базами данных, но это я, конечно, плохо помню - лет 5 прошло.
> А по сути это полностью то же самое. Только параметры, которые можно
> крутить, сгруппированы достаточно произвольным образом (исходя из
> средней по больнице температуры, включая морг) в несколько типичных
> групп. Что, однако, не мешает толстым клиентам заказывать
> специфические сборки под себя, когда они считают это выгодным.
Я не против перекомпиляции вообще. Если ставится нечто, что должно
работать настолько быстро, чтоб пыль столбом, то пожалуйста.
Hо compile time зависимость типа "c GNOME" или "без GNOME" - это бред
и его надо как-то исправлять или по-крайней мере должны быть способы
это сделать. Вот я и спрашиваю, кто-нибудь осознаёт, что проблема
существует или я просто со своим толмудом в чужой монастырь...
>
> >> Фигнаны. Есть проблемы. Особенно если взаимодействие компонент
> >> системы с окружением выполнено на препроцессоре (так
> >> эффективнее), и в функции не заворачивается.
> AC> Приложения, где нужна эффективность это не более 1%. 99% вполне
> AC> себе обойдутся непрямыми вызовами функций и даже без всякой
> AC> оптимизации. vim по-крайней мере не входит в список приложений
> AC> нуждающихся в супероптимизации и его функциональность вполне
> AC> можно было бы раскидать на кучу .so и "собирать" его
> AC> перечислением тебе нужных.
>
> Ага. Вот с таким подходом и получается мозилла, которая по 20 секунд
> грузится и по 5 секунд поднимает окно написания письма в ответ на
> кнопку "Compose".
Что есть этому причина - это ещё вопрос. Может XUL? Общеизвеcтный
факт: MS IE - один из самых быстых броузеров. Он насквозь состоит из
COM и не тормозит в отличие от... Вообще всё от мелкомягких пишется на
COM и далеко не все это тормозит. WORD, например, на порядок быстрее
AbiWorda.
Так что проблема не здесь.
>
> >> Это - правильный подход. Hо не всегда такая модульность возможна
> >> - библиотек много, они могут встречаться в самых разных
> >> сочетаниях и дёргаться из одного и того же модуля.
> AC> Вот я и говорю, к проектированию надо подходить очень серьезно,
> AC> поменьше "безжалосно рефакторить" и по-больше смотреть вперёд, а
> AC> не под ноги.
>
> "Безжалостно рефакторить" в XP относилось ко внутренним построениям
> и интерфейсам. То, что в open source его применяют к внешним,
> включая изменение ABI на каждый чих из-за добавления поля в
> структуру - это уже проблема open source народа и всяких Коксов,
> которые утверждают, что только так и нужно.
>
> > >> Если я не ошибаюсь, dlopen будет грузить либу на новое место в
> > >> памяти. Это, конечно, минус, но такой ли большой?
> >> Про недостатки плагинов тут уже говорилось. БОльшая проблема в
> >> том, что плагин всё равно надо собирать совместно с остальными
> >> частями софтины...
> AC> Чтобы такого не было, надо всего лишь отделить интерфейсы от
> AC> реализации и хорошо подумать над функциональностью каждого
> AC> компонента.
>
> Аксиомой является то, что нельзя заранее предугадать, что именно
> потребуется на каждом этапе развития. И куда будет развитие
> востребовано, а куда - нет. Hа всей Земле только один футуролог смог
> предсказать развитие цивилизации с хорошей точностью, у остальных в
> 2000 году цвели яблони на Марсе. А если залагаться на все варианты
> развития API с максимальной гибкостью - протокол взаимодействия
> должен быть ASN.1+BER. С соответствующим оверхедом и последствиями.
"Hе ошибается только тот, кто ничего не делает"
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
