|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Cheusov 2:5020/400 20 Nov 2002 16:28:31
To : Vitaly.Lugovsky@ontil.ihep.su
Subject : Re: kernel compiling
--------------------------------------------------------------------------------
Vitaly.Lugovsky@ontil.ihep.su writes:
> Aleksey Cheusov <cheusov@scnsoft.com> wrote:
>
> >> К примеру, включение/выключение всяких там
> >> логгеров/дебаггеров/профайлеров,
>
> > дебаггеры/профайлеры не нужны пользователям.
>
> Hужны. Им ещё и баг-репорты писать иногда надо. Если совесть есть.
Уболтал.
>
> > А программисты для
> > отладки пусть делают все, что хотят. Я не о них говорю. Тут Вагнер
> > пример приводил, когда они с Чуприной сидя на одной машине имели
> > разногласия в том, с какими опциями компилировать vim. Вот это я
> > считаю ненормальным.
>
> Считай как хочешь, но, ещё раз: на современном уровне развития IT эту
> ненормальность побороть невозможно в принципе. Изобретёшь обходной вариант -
> специально для тебя введут Hобелевскую премию за достижения в IT.
Hе понимаю. Виндозным юзерам перекомпиляция в голову не приходит
и работают же как то.
>
> >> выбор последовательного/многотредового/разфорканного варианта
> >> исполнения,
>
> > А так ли много приложений, которые могут и то и то одновременно?
>
> Достаточно.
>
> > А если и много, то простейший вариант здесь - основной цикл крутить
> > врутри либы, загрузив ее dlopen. Технических проблем здесь нет.
>
> Фигнаны. Есть проблемы. Особенно если взаимодействие компонент системы с
> окружением выполнено на препроцессоре (так эффективнее), и в функции не
> заворачивается.
Приложения, где нужна эффективность это не более 1%.
99% вполне себе обойдутся непрямыми вызовами функций и даже без всякой
оптимизации. vim по-крайней мере не входит в список приложений нуждающихся
в супероптимизации и его функциональность вполне можно было бы раскидать
на кучу .so и "собирать" его перечислением тебе нужных.
>
> >> отключение специфичных фичей, вносящих нежелательные зависимости от
> >> библиотек (ну на хрена мне emacs, линкованный с xlib, если наличия
> >> xlib вовсе не предполагается и тянуть его - мочи нет).
>
> > Делаешь промежуточный уровень в виде набора интерфейсов для
> > отображения/ввода и загружаешь или либу с xlib или что-нибудь
> > консольное. Если кому-то не нравится GUI emacsa, прикрутит себе
> > motif/gtk/qt или что-нибудь любимое.
>
> Это - правильный подход. Hо не всегда такая модульность возможна -
> библиотек много, они могут встречаться в самых разных сочетаниях и дёргаться
> из одного и того же модуля.
Вот я и говорю, к проектированию надо подходить очень серьезно, поменьше
"безжалосно рефакторить" и по-больше смотреть вперёд, а не под ноги.
>
> > Если я не ошибаюсь, dlopen будет грузить либу на новое место в памяти.
> > Это, конечно, минус, но такой ли большой?
>
> Про недостатки плагинов тут уже говорилось. БОльшая проблема в том, что
> плагин всё равно надо собирать совместно с остальными частями софтины...
Чтобы такого не было, надо всего лишь отделить интерфейсы от реализации
и хорошо подумать над функциональностью каждого компонента.
>
> --
>
> V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
>
--
Best regards, Aleksey Cheusov.
--- ifmail v.2.15dev5
* Origin: Science Soft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
