From: Michael Shigorin <mike@altlinux.org> To: devel-distro@lists.altlinux.org Subject: Re: [devel-distro] Веб-браузер в инсталляторе или для инсталлятора? Date: Fri, 18 Oct 2024 12:25:07 +0300 Message-ID: <20241018092507.GG8400@imap.altlinux.org> (raw) In-Reply-To: <70ee8512-6dab-4ae8-9a99-3c3d1a570543@gmail.com> On Tue, Oct 15, 2024 at 11:53:54PM +0300, Leonid Krivoshein wrote: > Я бы говорил иначе: при работе над конфигуратором нужен стиль > "веб-разработки" из фронтэнда, бэкенда и описания модели данных > (MVC), при котором интерфейсная часть модуля работает в > браузере или в том, что его заменяет, без внесения изменений в > кодовую базу. http://altlinux.org/alterator/architecture > Инсталлятор я бы упростил до минимума. Он должен запускаться > с LiveCD, это можно делать сразу после запуска общесистемного > конфигуратора. Тогда и не придётся сильно мудрить с его > архитектурой. Попробуй. Там так-то не старались мудрить, лишь бы намудрить -- скорее наслоения, чем архитектурное. > > Мне вот интересно. А кто у нас этим, вообще, пользуется, > > хотя бы через VNC? И кто будет пользоваться, если такую > > возможность реализовать? А ещё, насколько это актуально для > > "железных" машин, а не виртуалок. У серверных, "железных" > > машин обычно, для этих целей имеется IPMI (или аналоги). IPMI SP, который и реализует удалённую консоль -- даёт, гругря, VGA с клавомышью как раз в расчёте на "обычный" графический/текстовый инсталятор. > > А ставить в таком режиме сотни клиентских машин - > > сомнительная затея. Да; у нас на эту тему есть что рассказать gremlin@ как практику по датацентрам. > Типичный кейс -- безголовые сервера в датацентрах, всякие > недоустройства с COM-портом или коннектором USB, одним словом > всё, к чему монитор в реальной жизни не подключают даже на > время установки. Ну нет у них графической карты. Да. > > Кстати, следом за http появляется https и любителям веба > > хочется задать вопрос: "А с этим как быть? Жить на > > самоподписанных сертификатах на каждой инсталлируемой > > машине?". > Думаю, когда речь об установке единственной машины штатным > установщиком, вопрос о протоколах не возникнет, так как для > пользователя это будет подобно тому, что мы имеем сейчас -- > толстое приложение (мало ли что у него там внутри завёрнуто). > Он же сейчас использует QtBrowser и никак его это не бударажит > на предмет https. Потому что там нет https. > Если развёртывается много машин в большой сети, то чем плохи > самоподписанные сертификаты? <банальное> Тем, что их потребуется дотащить до всех браузеров, очевидно. И это или своя PKI, или головняк с потенциалом к дальнейшему росту пофигизма и реального ущерба безопасности на ровном месте. </> > Опять же, нынешний alterator-fbi только так и работает "из > коробки". Но ничто не мешает поменять сертификаты на более > правильные с т.з. политики компании. Для администрирования считаю более уместным заворачивать в SSH, чем в SSL. В том числе из-за глубокой порочности самого принципа SSL CA "кому-то там доверяю, не знаю". > > Ещё один момент про веб для инсталлятора, который даже > > обсуждать не хочется.... Звучит он так, что "на вебе вон чего > > делают, смотрите как просто! И разработчиков на рынке во > > сколько". > По крайней мере, проще тем, кто этим занимается постоянно, > нежели тем, кто занимается другой разработкой. Потому что они > на этом набили руку. И веб-разработчиков сейчас на рынке > действительно больше, чем нас. И результат типично ужасен -- "ой, ну и что, что не работает на вчерашнем браузере, зато посмотрите, какие уголочки!". Вплоть до дегенератов, которые умудряются сломать своими обмотками единственное важное поле ввода во всём магазине (у грамотных оно и без js будет работать, и на голом POST вообще хоть в lynx -- но грамотные нам не по карману). > > Честное слово, грустно думать даже, может быть сразу на > > дотнете начнём тогда? Дададад. И сразу под winapi, всё равно же libwine есть. > > - При этом, давать возможность делать простые, кривые, > > небезопасные фронты через веб - полная чушь. "через веб" тут избыточно, хоть там и наиболее очевидно. > > - Самые активные уже сейчас могут начать осваивать cockpit, > > в который нативно встраиваются интерфейсы на dbus. ...и пойти на курсы риторики, чтоб ещё более убедительно рассказывать про Самую Отечественную Разработку, ага. > > - Желающим написать срочно свой веб-движок, аналогичный > > cockpit, вне какой-либо модели безопасности предлагаю сначала > > подумать... (подробности в отдельной теме). ...о том, в чём предполагается отличие хотя бы целей для начала, а затем уж архитектуры и реализации (разумеется, изучив таковые по сравниваемому). > > На текущий момент сценариев "подключения множества > > разработчиков" предполагается несколько: > > > > 1) разрабатываемые в рамках unix-way бекенды могут быть > > встроены в реализованные толстые клиенты. > > > > Для этого требуется удовлетворять при реализации этих > > бекендов поддерживаемым уже разработанным фронтендами > > интерфейсам, которые лежат в соответствующих пакетах: > > - > > https://packages.altlinux.org/ru/search/?branch=sisyphus&q=alterator-interface- > > > > 2) для уже разработанных бекендов могут быть использованы > > разные фронты под разные задачи, графические окружения, > > а также консольные утилиты. > > > > Всё это достаточно понятно админам. Не вижу никаких для них в > > этом сложностей, если они хотят что-то разработать. > > Документацию будем наращивать. Примеры тоже будем создавать. И чем степень понятности отличается от уже имеющейся для собственно alterator? > > Вот, вроде хотим конфигуратор, а превращается всё в > > веб-интерфейс для ansible. "Когда в руке молоток..." :) > > Не понимаю что значит: "Если конфигуратор -- одна программа, если наш > > тулкит уже позаботился о взаимодействии фронт и бэк частей модуля, нам > > даже не надо об этом думать и остаётся только решить, в каких случаях > > уместно использовать кем-то написанное с использованием dbus, чтобы > > подтянуть и этот дополнительный функционал." > > > > Кто, о чём, как, почему должен позаботиться? (это риторический вопрос) > > > > Ответа, полагаю, просто нет. Архитектуры нет. Есть предположения о > > том, что если удачная архитектура кем-то будет реализована, то всё > > можно будет как-то сделать. > > > > Про удалённый доступ напишу в ответвлении про интерфейсы. "У меня архитектуры нет. Но то, что имеет архитектуру и вообще-то вывозило нас двадцать лет -- надо заменить" (ц) > Всё верно. Архитектуры нет, её только начали обсуждать. И да, > веб-морда для ansible прямо не называлась, но если мы не имеем > ресурсов и желания делать что-то своё, то хотя бы стоит > подумать об адаптации ОС Альт к таким готовым решениям, как > SaltStack+SaltGUI или аналогам. Из всех с кем имел дело по > технической линии и совместимости на самых крупных внедрениях > большинство либо на salt переходят, либо на коммерческие > допиленные аналоги salt из реестра. В том числе с ansible? (я здесь совсем не в контексте) > >>>>>> 1.4. Разве вебовский UI/UX сейчас не приоритетней? Смотря среди кого. > >> Какой веб-браузер будем использовать в установщике на e2k? > >> Или только по сети из Internet Explorer? Прямщас это Firefox 91. И нет, я приду в гости с кирпичом к тому, кто попытается мне такое навязать. -- Michael Shigorin http://altlinux.org/elbrus
next prev parent reply other threads:[~2024-10-18 9:25 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-10-08 13:43 [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Антон Мидюков 2024-10-08 23:13 ` [devel-distro] " Leonid Krivoshein 2024-10-08 23:29 ` [devel-distro] Тезисы для инсталлятора " Leonid Krivoshein 2024-10-09 2:13 ` Evgeny Sinelnikov 2024-10-09 21:52 ` Leonid Krivoshein 2024-10-14 7:17 ` [devel-distro] " Sergey V Turchin 2024-10-14 19:57 ` [devel-distro] Интерфейсы " Evgeny Sinelnikov 2024-10-14 21:23 ` Leonid Krivoshein 2024-10-14 21:57 ` Антон Мидюков 2024-10-15 1:11 ` Leonid Krivoshein 2024-10-15 4:49 ` Anton Farygin 2024-10-15 9:44 ` Michael Shigorin 2024-10-15 15:05 ` Denis Medvedev 2024-10-16 0:25 ` Leonid Krivoshein 2024-10-17 7:22 ` [devel-distro] " Sergey V Turchin 2024-10-15 19:29 ` [devel-distro] " Leonid Krivoshein 2024-10-17 7:27 ` [devel-distro] " Sergey V Turchin 2024-10-18 9:05 ` [devel-distro] [JT] мировоззренческое по путям развития Michael Shigorin 2024-10-15 5:19 ` [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Evgeny Sinelnikov 2024-10-15 23:02 ` Leonid Krivoshein 2024-10-15 10:30 ` [devel-distro] инсталятор как краеугольный камень выбора технологического пути Michael Shigorin 2024-10-09 1:40 ` [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл Leonid Krivoshein 2024-10-09 9:06 ` [devel-distro] " Sergey V Turchin 2024-10-09 19:46 ` [devel-distro] " Leonid Krivoshein 2024-10-10 19:29 ` [devel-distro] про API и фронтэнды Leonid Krivoshein 2024-10-10 23:27 ` Антон Мидюков 2024-10-11 0:33 ` Leonid Krivoshein 2024-10-14 7:27 ` Sergey V Turchin 2024-10-15 4:59 ` [devel-distro] Веб-браузер в инсталляторе или для инсталлятора? Evgeny Sinelnikov 2024-10-15 5:53 ` Антон Мидюков 2024-10-15 20:53 ` Leonid Krivoshein 2024-10-18 9:25 ` Michael Shigorin [this message] 2024-10-14 7:22 ` [devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Sergey V Turchin 2024-10-14 19:58 ` [devel-distro] " Leonid Krivoshein 2024-10-15 4:52 ` Anton Farygin 2024-10-15 19:30 ` Leonid Krivoshein 2024-10-15 6:33 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:32 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:49 ` [devel-distro] " Антон Мидюков 2024-10-17 8:44 ` [devel-distro] " Sergey V Turchin 2024-10-18 8:56 ` [devel-distro] qtbrowser vs wasm Michael Shigorin 2024-10-15 10:03 ` [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Michael Shigorin 2024-10-15 23:49 ` Leonid Krivoshein 2024-10-16 8:52 ` Michael Shigorin 2024-10-14 7:43 ` [devel-distro] " Sergey V Turchin 2024-10-14 10:54 ` [devel-distro] " Sergey V Turchin 2024-10-09 9:49 ` [devel-distro] " Alexey Gladkov 2024-10-09 19:54 ` Leonid Krivoshein 2024-10-10 9:10 ` Alexey Gladkov 2024-10-10 12:21 ` Leonid Krivoshein 2024-10-10 14:31 ` Alexey Gladkov 2024-10-09 6:19 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Ivan A. Melnikov 2024-10-09 7:21 ` Антон Мидюков 2024-10-09 9:21 ` [devel-distro] " Sergey V Turchin 2024-10-09 13:08 ` [devel-distro] " Leonid Krivoshein 2024-10-09 13:56 ` [devel-distro] о голосовом управлении (was: Тезисы для инст, альтератор 2.0) Arseny Maslennikov 2024-10-10 8:11 ` [devel-distro] о голосовом управлении Антон Мидюков 2024-10-14 7:33 ` [devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0 Sergey V Turchin 2024-10-09 22:08 ` [devel-distro] " Leonid Krivoshein 2024-10-10 1:01 ` [devel-distro] Пример файла разметки и описания Leonid Krivoshein 2024-10-10 8:54 ` Антон Мидюков 2024-10-10 5:26 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Антон Мидюков 2024-10-10 10:29 ` Leonid Krivoshein 2024-10-14 4:58 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог) Антон Мидюков 2024-10-14 18:59 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20241018092507.GG8400@imap.altlinux.org \ --to=mike@altlinux.org \ --cc=devel-distro@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git