Re: [devel-distro] Очень простой конфигуратор

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/18/24 23:01, Paul Wolneykien wrote:
>    Всем привет.
>
>    В соседних обсуждениях по конфигуратору и инсталлятору был высказан
> ряд тезисов:
>
>    1. первоначально предполагалось появление консольного установщика
>       (его порой [не хватает?]);

Возможно это было лет 15-20 назад. Сейчас же речь шла о безмолвной 
развёртывалке, которая выполняет работу установщика по готовому файлу 
ответов. Будет ли при этом маячить на переднем плане GUI ползунок с 
меняющимися слайдами или же будут бежать сообщения в текстовую консоль 
-- вопрос десятый, он зависит только от того, кто и как запустит эту 
развёртывалку. Чего точно не требуется -- конфигурировать установку в 
текстовом режиме.

>    2. в том числе и для безголовых (админов, хи-хи) серверов в
>       датацентрах с COM-портом;

У такого установщика вообще нет фронэнда никакого, т.к. нет видеокарты. 
Фронтэнд на другом конце провода. Это всё та же безмолвная развёртывалка 
(silent autoinstaller).

>    3. нужна дружественность к людям с ограниченными возможностями;

Желательно. Для установщика в GUI.

>    4. важен адаптивный интерфейс для устройств с маленьким экраном;

Вопрос дискуссионный. Речь была о конфигураторе. Конечно, желательно 
иметь возможность поменять доменные политики или помониторить свои 
сервера, находясь в срочной командировке на Мальте. Но на такой случай и 
ноутбук можно взять, чем мыкаться с телефоном. К сожалению, именно 
адаптивный интерфейс обычно сужает выбор инструмента и ограничивает 
подход к проектированию интерфейса.

>    5. если хочется, чтобы установщик или конфигуратор был не только
>       в браузере, достаточно единой кодовой базы для интерфейсов
>       фронтендов;
>    6. эта база должна крайне медленно устаревать (вместо "не работает
>       на вчерашнем браузере");
>    7. и по-возможности быть декларативным (!) описанием фронтенда;

Да.


>    8. юниксы вырвались вперёд на простоте, человекопостижимости;

Не думаю, что они особо куда-то вырвались, но они надёжны.


>    9. не должно быть экспоненциального роста сложности для развития
>       и поддержки системы конфигурации;

Да.


>   10. потребительские качества программы должны оцениваться с позиций
>       потребностей высококультурного, воспитанного человека;
>   11. ибо заботиться о людях --- не значит потакать их немощам, но
>       помогать им преодолеть их.
>
>
>    Хочу сказать, что по первому пункту имею некоторые наработки. Однажды
> (судя по git это было 12 лет назад) на архитектурной базе нашего
> альтератора был разработан ряд модулей для настройки сторонних
> (и проприетарных) программ и, частично, для настройки базовой системы
> Альт-СП в плане сети. Для последнего были заменены или дополнены
> стандартные модули типа alterator-net-eth. Почему же это потребовалось?
> Дело в том, что первым условием того заказа было... чтобы конфигуратор
> работал в консоли.
>
>    К сожалению, весь код целиком не сохранился. Но сохранилась
> shell-обвязка вокруг woo, имитирующая alterator/woo на scheme [1],
> а также вторая библиотека, непосредственно предназначенная для
> построения текстовых диалоговых интерфейсов [2] на базе dialog(1).
>
>    Сразу добавлю, что похвастаться в этом коде особенно не чем: я сейчас
> поглядел, там eval на eval и eval погоняет; часть из них явно не нужна,
> а остальные --- не санитизируются. Но речь на самом деле не об этом
> конкретном коде. А о том, что когда-то существовал вполне рабочий
> прототип из 5--7 модулей альтератора, построенных по диалоговому
> принципу. Что показал данный эксперимент? Он показал и доказал
> практически, что бэкенды на базе alterator/woo, написанные с оглядкой
> на index.scm и index.html, могут быть использованы также с принципиально
> иной структурой фронтенда, зажатого в узкие рамки таких категорий UI
> как "двойственный выбор", "множественный выбор", "подтверждение или
> отказ", "ввод данных" и --- главная особенность --- "уровень,
> подуровень, под-подуровень, и т. д." (вместо одного сложного окна
> дерево простых).
>
>    Что тогда послужило отправной точкой? Кажется, для соседнего проекта
> нужно было собирать кастомизированные ядра, а значит перед глазами
> был диалоговый конфигуратор ядра. Было вполне логично реализовать
> подобное на имеющейся базе alterator/woo + backend3. И это что-то
> получилось: уж не знаю, благодаря данной архитектуре или же вопреки
> ей.
>
>    Что можно сказать о диалоговой структуре UI сегодня, в том контексте,
> который определили соседние обсуждения по конфигуратору и инсталлятору?
> Номера пунктов соответствуют тезисам в начале данного письма.
>
>    Во-первых, она с лёгкостью покрывает пп. 1, 2, 3 и 4. В частности,
> для п. 3, посредством замены dialog(1) альтернативной программой,
> реализующей потоковое текстовое меню и добавлением TTS, получаем
> настоящее голосовое меню, которое не нужно "табать" в поисках этих
> странных кнопок из мира зрячих. Для реализации п. 4, опять же,
> достаточно заменить саму dialog(1) на подходящую графическую реализацию
> меню.
>
>    Во-вторых, пп. 5--7. С ними тоже тут нет никаких проблем. Более того,
> на действительно декларативном уровне я не могу представить ничего,
> кроме описания кейсов вопрос-ответ. Любое другое "декларативное"
> описание UI на проверку оказывается пустой рекламной декларацией
> разработчика (продажника), поскольку обязательно оперирует такими
> плоскими (двухмерными, то есть) понятиями, как "панель", "кнопка",
> "маркировка" (label), "100% по ширине", "по левому полю" и т. д.
> Пустой декларацией оказывается в таком случае "переносимость",
> "независимость от платформы" и пр.
>
>    По сравнению с такими обещаниями переносимости и независимости
> конфигуратор ядра Linux ведёт себя очень и очень зерьёзно. Из
> текстового он без труда превращается в графический ("на той же
> кодовой базе", п. 5), его не трудно вообразить и в 3D/VR. Но конечно,
> при всех возможных тут красивостях и даже украшательствах,
> пользователь, в итоге, всё равно оказывается перед выбором из тех же
> самых вопросов и альтернатив, которые заложены в диалоговое дерево и
> ради получения ответов на которые и запускается конфигуратор. И это ---
> очевидный минус, скажет кто-то.
>
>    Но минус ли это на самом деле? Если мы, в-третьих, посмотрим на
> оставшиеся тезисные пункты 8--11, то можем рассчитывать на вполне
> положительный отзыв насчёт простоты (разработки) и "олдскульности"
> (в хорошем смысле) использования диалоговой структуры.

Всё немножечко зависит от того, какими данными и как будет оперировать 
конфигуратор. Потому что одно дело -- включить/отключить сборочную 
опцию, и в самом сложном случае дописать текстовое значение в поле, и 
другое дело -- современный диалог с выбором точки на карте для указания 
временной зоны. Вся олдскульность уходит на пенсию.


>    Важный момент. Каким неоспоримым преимуществом обладает диалоговый
> интерфейс для настройки чего-либо? В соседних обсуждениях об этом,
> кажется, никто не говорил (или я пропустил). А вот каким. На мой
> взгляд, древовидная структура --- единственная до конца и полностью
> документируемая структура. Причём, однозначно документируемая.

Да, дерево -- интуитивно понятный и наиболее часто используемый элемент 
в классических конфигураторах. Я приводил примеры: RSAT & Ко, РедАДМ. 
Когда речь о тысячах модулей, кнопочками туда/сюда не полистаешь, дерево 
напрашивается и в том случае, когда мы классифицируем большое число 
настроек, когда мы ставим одно в зависимость от другого, когда мы хотим 
делегировать полномочия на целый куст настроек или когда наше дерево, 
подобно структуре LDAP, собирается из разных частей и хранится в некоей 
распределённой системе.


> Все остальные варианты конфигуратора требуют написания
> иллюстрированной документации со снимками экрана, которая из-за этого
> страдает неоднозначностью и рискует потерять свою актуальность с
> каждой сменой брэндинга и графического тулкита. Хотя я при этом совсем
> не против иллюстраций, нет. Но согласитесь, что мануал по настройке
> ядра с иллюстрациями текстовых боксов на 100% годится и в том случае,
> если я использую "make xconfig". Это потому, что пользователь работает
> здесь с логической структурой, которая не меняется.
>
>    Теперь предложение.
>
>    Как вы уже поняли, лично мне идея диалогового конфигуратора
> (инсталлятора) кажется интересной и перспективной. И я бы даже взялся
> за её реализацию. Однако в одиночку что-то тащить очень тяжело.
> Особенно, если это что-то потом или сразу окажется не нужным.
> Поэтому предложение к единомышленникам, если таковые, конечно, имеются:
> а) отозваться; б) поделиться наработками (хотя бы и теоретическими);

Первоочередной вопрос, который надо решить:

https://lists.altlinux.org/pipermail/devel-distro/2024-October/003066.html

Из него вытекает многое. Если готовы идти по пути 1, стоит определиться 
с БД конфигурации, её API для фронтенда и бэкенда, механизмом её 
взаимодействия с rpm и другими глубоко альтовыми вещами. Мне кажется, 
что проще и намного лучше иметь API для работы с этой БД, нежели 
выстраивать иные виды взаимодействия. Тогда и конфигурация будет 
доступна не только в пределах конфигуратора, и подходы к конфигурации 
будут едиными.

К примеру, механизм debconf по API очень похож на наш woo, только там 
база, у нас же её нет, всё в пределах модуля: man 7 debconf-devel. И 
через этот механизм организован интерактивный диалог, что лично мне не 
нравится, т.к. я убеждён, что это фронтенд должен дёргать и управлять 
бэкендом, а не наоборот. Просто у них бэкендов уйма, фронтенд один.


> в) организоваться в рабочую группу по данному вопросу.
>
>
> ---
> [1]:
> git://git.altlinux.org/people/manowar/packages/alterator-dialog-functions.git
> [2]: git://git.altlinux.org/people/manowar/packages/dialog-framework.git

-- 
WBR, Leonid Krivoshein.