From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729298188; x=1729902988; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=HoFtq8gzk11YmZ5GAtvTd7DGiCZpHI7bX3aFyAcYqyA=; b=l3Jd4XXHcXHJHQDEaKCDaEjHC6tD4+0Bwc4J6ClnXUbDdCmQZwtrZvBMzzdhyavAXO LpavcYpmyzzOP2jVoAjpw20VCuDfFi2ijPiqO2kx0gNM2HramXmcz97AtIguiTTNdr5z pFW1iGDCMlNh7e1683TbArr+e5bKrleQRd1npwFkx87SHtaKJyCgiR0kP1hWaEFoBCK2 C2tMhrgoeduxdTwO5oMAgbS6TnS59r8XKFNSGjUrVbzVexchHDAajujX+hXIeASkR12C s9fD8ioV/jvmYiL243aBhLznTHGVDr75cjwRKK8X/TNC8H8MluiYzcNk5Jx5o3w3lXyj PG6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729298188; x=1729902988; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HoFtq8gzk11YmZ5GAtvTd7DGiCZpHI7bX3aFyAcYqyA=; b=F9I7hnQn9ZGQTwBk4tz66OwDRXJ2skCgbTxMfMqEzA5rqcruB09/DGTx9jm922PKqz m+bRMFf5E60Rxyf/0GXwf3c/YQ6l/otvR3nyprZ8vkUI95fIdGj3tl1LU09Aa1y8g6Tt dWyKAzimTMaB0n/uA/w81yrtoSzJn2Q8vmQka7YZT7AKIURJ9eYrYdGBpZuLlVnfpiS7 sADpjgoIR68Rcs5e42w1Hf1AU/XBPwdjQI9LaQwOn7D9cyJGMHpuKhtCAK3qQfAdH+BF itusrEkDMVgueR7YKNE5Ot08+iqV7TJ0Ca1vLty2zF554ZTptARjyohShJ8dRWaT7C1C rtxA== X-Gm-Message-State: AOJu0YzwOTlDl+dVfy3bKtUR/Ic7Lb9zJDTwy+DG0jrjlhixkkq9pp09 KrksE/9H1aVnyKYAjbjxXmdaF427UDGhXT6ZFdwjme24mVT4nPNhkfRnJQ== X-Google-Smtp-Source: AGHT+IFUyBEdRGgVFkwB0q1tOS1yi5RsnuWGbsrSgNThHkDwLDWXUeWyYThkN2EjaDfW7XU3DSfWnQ== X-Received: by 2002:a05:6512:3b97:b0:536:a6c6:33f with SMTP id 2adb3069b0e04-53a15218d07mr3033036e87.13.1729298185967; Fri, 18 Oct 2024 17:36:25 -0700 (PDT) Message-ID: Date: Sat, 19 Oct 2024 03:36:22 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: <20241018230115.41a83cf0@legato> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: <20241018230115.41a83cf0@legato> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0J7Rh9C10L3RjCDQv9GA0L7RgdGC0L7QuSDQutC+?= =?utf-8?b?0L3RhNC40LPRg9GA0LDRgtC+0YA=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2024 00:36:31 -0000 Archived-At: List-Archive: 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.