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

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

[Paul Wolneykien]

  Всем привет.

  В соседних обсуждениях по конфигуратору и инсталлятору был высказан
ряд тезисов:

  1. первоначально предполагалось появление консольного установщика
     (его порой [не хватает?]);
  2. в том числе и для безголовых (админов, хи-хи) серверов в
     датацентрах с COM-портом;
  3. нужна дружественность к людям с ограниченными возможностями;
  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, то можем рассчитывать на вполне
положительный отзыв насчёт простоты (разработки) и "олдскульности"
(в хорошем смысле) использования диалоговой структуры.

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

  Теперь предложение.

  Как вы уже поняли, лично мне идея диалогового конфигуратора
(инсталлятора) кажется интересной и перспективной. И я бы даже взялся
за её реализацию. Однако в одиночку что-то тащить очень тяжело.
Особенно, если это что-то потом или сразу окажется не нужным.
Поэтому предложение к единомышленникам, если таковые, конечно, имеются:
а) отозваться; б) поделиться наработками (хотя бы и теоретическими);
в) организоваться в рабочую группу по данному вопросу.


---
[1]:
git://git.altlinux.org/people/manowar/packages/alterator-dialog-functions.git
[2]: git://git.altlinux.org/people/manowar/packages/dialog-framework.git

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

[Leonid Krivoshein]

Добрый вечер!


On 10/18/24 23:01, Paul Wolneykien wrote:
>    Всем привет.
>
>    [...]
>
>    Теперь предложение.
>
>    Как вы уже поняли, лично мне идея диалогового конфигуратора
> (инсталлятора) кажется интересной и перспективной. И я бы даже взялся
> за её реализацию. Однако в одиночку что-то тащить очень тяжело.
> Особенно, если это что-то потом или сразу окажется не нужным.
> Поэтому предложение к единомышленникам, если таковые, конечно, имеются:
> а) отозваться;

Поскольку я принимал участие в переходе на grub в наших ISO, 
периодических починках и усовершенствованиях установщика, выполнил 
обещание по замене пропагатора [3], и с 2017 активно продвигаю деплойную 
технологию [4], благодаря которой ОС Альт ставился за эти годы на многие 
тысячи рабочих мест, не задавая вопросов и не используя штатный 
установщик, меня можно учитывать в части переделки будущего инсталлятора.

При этом я полностью согласен в этом вопросе с mike@: сначала придётся 
сделать нормальный бэкенд разбивалки диска и я этим вопросом собираюсь 
вплотную заняться, тем более, что обещал очень давно. Без этого 
указанная выше цепочка замены не может быть продолжена. Основной 
системный конфигуратор, на мой взгляд -- другая история. И если сейчас 
пытаться их жёстко связать, будет сложнее и больнее.

Ранее я делал простые текстовые установщики, когда ещё сидел на Debian, 
сегодня текстовый интерфейс конфигурирования неактуален, не стоит на 
него ориентироваться.


> б) поделиться наработками (хотя бы и теоретическими);

1. В этой рассылке начали дискуссию в правильном направлении. Нужно не 
просто высказывать точку зрения, а ещё и обосновать её. Тезисы с 
наиболее убедительными доводами могут лечь в основу техзадания к 
будущему конфигуратору и установщику.

2. Как часто у нас водится, кто бы что не говорил, но если пользоваться 
больше нечем, то пользуемся тем, что есть. И пока ты сам не сделаешь, 
или пока кто-то не сделает, так и будем пользоваться имеющимся. Так что, 
здесь дорогу осилят заинтересованные в данном вопросе разработчики, 
обладающими временем для этого, а среди нас таких немного. Не волнуйся, 
втихаря сделать никому не нужное не получится, т.к. слишком большая и 
больная тема --  том смысле, что инициативу здесь никто не уведёт. ))

3. Отдельно готов рассказать в общих чертах про устройство конфигуратора 
в Debian. Особенность его в том, что ему лет 30 и он с самого начала 
тесно интегрирован с древнейшим пакетным менеджером. Другими словами, у 
Debian и основанных на нём есть какая-никакая штатная система 
конфигурирования, удобно обслуживаемая маинтейнерами и администраторами 
база данных конфигурации, отдельная от пакетов, 20% из которых покрыты 
этой БД конфигурации, потому что далеко не все пакеты в репо требуют 
какого-то особого конфигурирования. В RedHat и отделившихся такого не 
было изначально, откуда вытекают ранее озвученные проблемы не 
обслуживаемых файлов конфигурации в пакетном дистрибутиве, отсутствие 
единой базы переносимой конфигурации.


> в) организоваться в рабочую группу по данному вопросу.

4. Считаю, что существенная часть конфигуратора должна быть на sin@ и 
его ближайших коллегах, поскольку много пересечений с групповыми 
политиками и в числе целей -- управление конфигурацией хостов с ОС Альт 
средствами Альт домена, а также апстрим этих наработок в samba.org. 
Возможно, у sin@ другие соображения, и ему было бы проще, чтобы 
конфигуратор уже был готов, и просто его использовать, чтобы 
сфокусироваться только на доменном функционале. Насколько я знаю, это не 
так, Альтератор 2.0 даже его инициатива.

5. Основной ремонтник и усовершенствователь нынешнего установщика в 
последнее время -- antohami@, к тому же на нём m-p. Да и всем 
релиз-менеджерам вопросы конфигурирования и установки близки. Так что, 
хотя бы в режиме чтения группа получится не маленькой, если не почти 
весь devel-distro@. :-)


> ---
> [1]:
> git://git.altlinux.org/people/manowar/packages/alterator-dialog-functions.git
> [2]: git://git.altlinux.org/people/manowar/packages/dialog-framework.git

[3]: https://www.altlinux.org/Installer/common/altboot
[4]: https://www.altlinux.org/Rescue/Deploy


-- 
WBR, Leonid Krivoshein.

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

[Leonid Krivoshein]

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.