[devel] Два цента на Альтератор (was: [usability] Работа Alterator от пользователя)

Aleksey Novodvorsky aen на altlinux.ru
Пт Июн 11 04:44:59 UTC 2010


10 июня 2010 г. 23:17 пользователь Michael Pozhidaev <msp на altlinux.ru> написал:
> Hello, Aleksey Novodvorsky!
>
>> Нет. Проблема в том, что нет внятных текстов по перспективе разработки
>> принципиально новой версии. пока их нет -- дорабатываются и
>> разрабатываются модули для текущей в рамках коммерческих заказов и
>
> Позвольте мне пару центов, с удовольствием бы обсудил это в Переславле,
> но в этот раз я только заочно.
>
> при всём уважении к авторам уже существующего варианта, главным
> недостатком, мне кажется, была сильная незаменяемость отдельных
> слоёв. Точнее, не сама незаменяемость, а крайне дикая по затратам
> ресурсов сложность создания альтернатив. Написать новый фронтент,
> который под какую-нибудь задачу должен обладать сильно ущербной
> функциональностью, очень тяжело, в то время как обычно гибкие системы
> тем и хороши, что первое начальное приближение легко
> достижимо. Существует допущение, что всё должно укладываться в интерфейс
> на scheme. Сталкивался с  этим по своей специфике работы, и решения пока
> нет.

Да, написание фронтендов -- проблема.

>
> Как следствие, предложил бы сделать упор на структурированные
> интерфейсы, по которым может гулять информация (D-Bus?). Для каждого
> модуля прежде всего забивать формат структур, специфичных для этой
> задачи, а дальше дать полную свободу по реализации вверх к пользователю
> и вниз к к back-end'ам.
>
> Сколько было перебрано здесь возможных вариантов языков, так это
> очевидно, что устраивающего всех варианта нет.
>
> Вот, например, сделать консольный установщик (не терминальный, а именно
> консольный) ныне крайне тяжело. back-end'ы работают все по-разному, за
> всем не уследить, и надежды на поддержку в актуальном состоянии тоже нет
> никакой.
>
> Ну и при допущении, что   при достаточном количестве аргументов каждый
> может попытаться сделать что-то своё на python или чём другом, конечно,
> должна быть реализация по умолчанию.
>
> Ещё раз: акценты делать нна структурирование интерфейсов. В терминологии
> компонентной модели, как, в COM у форточек или в другом виде, не так
> важно.
>
> Я могу сказать вообще страшную мысль, мне не казалось бы сделать
> для своих задач какой-то центр управления частью параметров системы на Java(Swing),
> т.к. нужные задачи решаются, а затраты памяти и прочее, ну как
> получится.
>

Вот последнее -- плохо, особенно учитывая современные тенденции, в
частности все большее число задач для ограниченного железа, например
устройств на arm. На самом деле, именно компктность альтератора стала
его главным козырем, позволила нам в течение некоторго времени быть
лидерами в части нетребовательного к памяти  установщика с
дружественным интерфейсом. И я не стал бы от этого отказываться.
Проблема, на мой взгляд, в другом. Не в альтераторе, а в надеждах на
его универсальность. Он хорошо решает свои задачи. А не свои не
решает. Пусть новая система, если будет, рещает свои задачи. Она не
обязана быть установщиком.

Rgrds, Алексей


Подробная информация о списке рассылки Devel