LINUX.ORG.RU

Какой вектор развития дистрибуции и пакетирования пользовательских программ вы считаете наиболее интересным и/или перспективным

 


0

1

В скобочках приведены примеры, чтобы лучше понимать суть.

  1. Пакетные менеджеры с поддержкой установки различных версий пакетов (nix)177 (42%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Кроссдистрибутивные системы управления пакетами (flatpak)113 (27%)

    ************************************************************************************************************************************************************************************************************

  3. Создание пакетов "всё-в-одном" (appimage)110 (26%)

    ******************************************************************************************************************************************************************************************************

  4. Использование статической линковки для достижения кроссдистрибутивности79 (19%)

    **********************************************************************************************************************************************

  5. Другой67 (16%)

    *************************************************************************************************************************

  6. BSD (порты FreeBSD)56 (13%)

    *****************************************************************************************************

  7. Кроссплатформенные веб-приложения (PWA, wasm)54 (13%)

    *************************************************************************************************

Всего голосов: 656, всего проголосовавших: 426

★★★

Проверено: Satori ()

Ответ на: комментарий от James_Holden

Считаю что вот это никогда не должно стать основным способом распространения софта, иначе это убъет Линукс.

Создание пакетов «всё-в-одном» (appimage)

Использование статической линковки для достижения кроссдистрибутивности

иначе это убъет Линукс.

Почему на двух остальных системах сделано так изначально, и это их не только не убило, но и позволило иметь на 1-2 порядка большую долю рынка, а линукс, который не может преодолеть 2% доли благодаря замечательной системе репов, исправление в нужную сторону обязательно убьет?

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

Во-вторых, что касается десктопов, долю рынка «двух остальных систем» обеспечила активная маркетинговая стратегия, а совсем не то, о чем мы общаемся в этой ветке. Большие пакеты являются одним из тех факторов, почему что люди всё ещё смотрят в сторону альтернатив.

В-третьих, подход «всё в одном» как минимум увеличивает требуемый объем памяти для приложения - как дисковой, так и оперативной, ну и заодно требования к сети. Но не это главное. Главным злом является усложнение обновления. Предположим в какой-нибуть популярной либе, которая используется в десятках приложений, закрыли критическую уязвимость. При классическом подходе, вам достаточно обновить лишь либу, и уязвимость будет закрыта во всей вашей системе. А вот если эта либа статически слинкована со многими приложениями, то вам придется обновлять их всех. И это при условии что обновления для всех этих пакетов будут оперативно сформированы. Ради чего все эти усложнения - непонятно.

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 10)

Пожалуй, ничего лучше pkgng+ports в freebsd еще не придумали

Ляликсу до этого как пешком до луны. Gentoo конечно молодцы, но из-за ТАКОЙ гибкости работать с этим всем хламом становится слишком сложно и геморно.

reprimand ★★★★★ ()

Всем преклониться перед могуществом Nix (или его будущего потомка) и юзать только его.

t184256 ★★★★★ ()
Ответ на: комментарий от James_Holden

Февраль 2019 года

Ну ты понимаешь, что 2.5 года — это совсем смешной срок.

Про маленький смешно. Это постоянно пишут, что развеиваемая технология, и ещё новая.

https://ru.wikipedia.org/wiki/Flatpak

fornlr ★★★★★ ()
Ответ на: комментарий от thesis

Говно в том, что люниксоиды ниасилили нормальную поддержку зоопарка версий либ и нормальный пакетный менеджер.

Два стула тут в том, что или ты ставишь вообще все либы (потому что они друг от друга тоже зависят) или ставишь срез (меньше, но со старьём или роллинг со свежаком, но без нужного/стабильного старья). И ничего ты не сделаешь с этим, проблема фундаментальная и не решается никаким пм.

crutch_master ★★★★★ ()
Ответ на: комментарий от James_Holden

Нет значит напишем и будут

Есть линукс, где есть только кутэ и гтк.
Есть венда, где есть только винапи.
Есть планшет, где какая-то своя херня.
А рисовать интерфейс везде как-то надо. И желательно, чтобы это было единообразно и не приходилось изобретать каждый раз велик или портировать очередную версию куте (или что у вас там) и тащить на целевую систему весь зоопарк либ. Системные программисты с этим, отчасти, справились, а прикладники даже не пытались и еще лет 50 будут по углам дрочить.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от James_Holden

Допустим. Что предлагаешь?

Какой вектор развития дистрибуции и пакетирования пользовательских программ вы считаете наиболее интересным и/или перспективным (комментарий)

Нормальное решение же в том, что надо плясать от интерфейса взаимодействия

crutch_master ★★★★★ ()
Ответ на: комментарий от Kroz

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

Вот не надо, все уточнялось не раз.

Во-вторых, что касается десктопов, долю рынка «двух остальных систем» обеспечила активная маркетинговая стратегия, а совсем не то, о чем мы общаемся в этой ветке.

Если «активную маркетинговыю стратегию» применить к линуксу, это не поможет, потому что люди не могут понять как им пользоваться такой системой и нафига вообще такие сложности при установке приложений. Поэтому надо сначала решить эту техническую проблему.

А «стратегия» применялась и не раз. Одна только раздача каноникалом бесплатных дисков по всему миру чего стоит. Предустановки тоже были в каждом магазине компов. Все это дало нулевой результат.

Большие пакеты являются одним из тех факторов, почему что люди всё ещё смотрят в сторону альтернатив.

Я не знаю таких пользователей винды, которых бы задумывались о чрезмерном размере инсталляторов программ.

В-третьих, подход «всё в одном» как минимум увеличивает требуемый объем памяти для приложения - как дисковой, так и оперативной, ну и заодно требования к сети.

Это незначительное увеличение. Но тут имеет значение, какие именно пакеты. Если AppImage то может быть и значительное. Если Flatpak то там дедупликация между пакетами.

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

Да, поэтому именно статическая линковка - плохой выход. Опять же лучше Flatpak. С ним, во-первых, либа скорее всего будет в общем рантайме, который тут же обновят.

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

Обновление всех пакетов в даном случае не сожрет сеть, потому что обновление во флатпаке делается коммитами (то есть дельтами), и с дедупликацией между пакетами. То есть это исправленная либа просто по сети прилетит один раз, а потом OSTree сформирует для каждого пакета рабочую версию с новой версией либы. Это в самом худшем случае - если либа прямо запакована в пакеты приложений была. Если она в рантайме - то все еще проще, обновится просто рантайм.

James_Holden ()
Ответ на: комментарий от crutch_master

А конкретнее?

Вот ты пишешь

и не приходилось изобретать каждый раз велик или портировать очередную версию куте (или что у вас там) и тащить на целевую систему весь зоопарк либ

И что? Как GUI рисовать без всего этого?

В браузере? Так его еще сложнее портировать на поярдок и он еще больше тянет либ на порядок.

James_Holden ()
Ответ на: комментарий от James_Holden

Я не знаю таких пользователей винды, которых бы задумывались о чрезмерном размере инсталляторов программ.

Вот недавно одному помог, подсказав про c:\nvidia

А то место на диске C закончилось, а тут на тебе и целый гигабайт за даром.

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от James_Holden

И что? Как GUI рисовать без всего этого?
В браузере?

При чём тут браузер? Ты вообще можешь думать как-то отлично от default?
Нет разницы на чём рисовать по большому счёту. Хоть на кутэ, хоть на сдл и фреймбуфере, хоть в браузере, хоть винапи или что-то еще. Важен интерфейс. Язык для общения клиента и сервера - рисовалки/нажималки кнопок. Тебе есть разница что там стоит на серваке и какой версии апач/tomcat/nginx/нода? Нет. Апачу есть разница, какой у тебя браузер/curl? Тоже не особо. Теперь представь, чтобы зайти на лор, тебе надо яву и набор каких-то там ява либ. Чтобы найти на другой сайт надо рантайм гошечки. Бред? Бред. Почему для гуя это не бред? Тебе надо, чтобы гуй что-то нарисовал, ну он и нарисует. Надо, чтобы он как-то отвечал, ну он и будет отвечать. Сиди и общайся с ним через программный интерфейс. Какая тебе разница, что там на том конце?

crutch_master ★★★★★ ()

Учитывая, что я прямо сейчас использую несколько приложений из flatpak (obsidian, kdenlive и telegram) и они работают, в целом, нормально и малоотличимо от дистрибутивных пакетов – меня это устраивает.

А вообще, если автору лень морочиться с пакетами, меня устраивает какой-нибудь архив все-в-одном, который можно просто распаковать в ~/apps и запустить бинарник. Для большего удобства закинуть скрипт запуска в $PATH и appname.desktop в ~/.local/share/applications.

Im_not_a_robot ★★★★★ ()
Последнее исправление: Im_not_a_robot (всего исправлений: 2)
Ответ на: комментарий от crutch_master

Какая тебе разница, что там на том конце?

Всмысле какая? Этот конец у меня на компе. Мне все равно придется ставить ноду, апач, пхп или что там будет использоваться. В случае с сайтом все это уже поставили за меня на сервер, и да, меня дальше не волнует что там.

В случае с оффлайн приложением все это ставить надо мне, и тут я не вижу никакой разницы с установкой GTK, Qt и так далее.

James_Holden ()
Ответ на: комментарий от Kroz

Но не это главное. Главным злом является усложнение обновления. Предположим в какой-нибуть популярной либе, которая используется в десятках приложений, закрыли критическую уязвимость. При классическом подходе, вам достаточно обновить лишь либу, и уязвимость будет закрыта во всей вашей системе

На практике так не работает.

Если у тебя есть приложение, у которого автор нюхает клей и кладёт на безопасность, то твои вращения с секурными обновлениями либ мало о чём. Это ещё если можно обновить. А то там EOL, broken API и всё такое.

А на практике даже наоборот получается. Можно вспомнить про серьезную уязвимость с VLC недавнюю. Точнее не в самом а в библиотеке. И?…

Так пользователи Windows и macOS пользуются безопасной версией, а пользователи Ubuntu LTS по заветам дедов сидят с дарами, ибо надо же ещё, чтобы и в проекте либы чётко сообщали о секурных исправлениям и чтобы в самом дистрибутиве мейнтнйнеры следили бы внимательно за этим.

В теориях же всё замечательно звучит.

fornlr ★★★★★ ()
Ответ на: комментарий от James_Holden

Мне все равно придется ставить ноду, апач, пхп или что там будет использоваться

Использоваться будет что-то одно. По сути не важно какая именно софтина, главное, чтобы она умела x,y,z.

В случае с оффлайн приложением все это ставить надо мне, и тут я не вижу никакой разницы с установкой GTK, Qt и так далее.

Странно. Я всегда думал, что разница между «это всё» и «любое из этого» существенная.

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

Использоваться будет что-то одно.

Почему? Кто мешает сейчас использовать только Qt? Вот кто-то мешает. И этот же кто-то обеспечит зоопарк и по твоей схеме. И все это придется ставить.

Тем более что в вебне это зоопарк уже есть и он еще намного хуже зоопарка у прикладников. Так как ты предлагаешь его преодолевать?

«это всё» и «любое из этого»

Любое из этого тут не поможет, вася наваяет на php а маша на ноде, и будешь ставить и то и другое.

А если у тебя есть идеи как этот зоопарк победить, то почему бы таким же методом не сделать единый тулкит для всех приложений и всех ОС?

Я пока не вижу смысла все еще.

James_Holden ()

Надо запилить такой дистр, в котором flatpak будет родным пакетом. Не в том смысле, что запускаться как flatpak а в том, чтобы устанавливался, как , например, deb в Дебиане.

Psilocybe ()
Ответ на: комментарий от Psilocybe

Пока мало приложений, сложно будет реализовать.

Но, видимо, всё к этому идёт.

fernandos ★★★ ()

поклонники единой системы должны умереть
покайтесь 💩 поклонники пока еще не поздно

nanosecond ()
Ответ на: комментарий от James_Holden

Почему? Кто мешает сейчас использовать только Qt?

Те, кто соби

И этот же кто-то обеспечит зоопарк и по твоей схеме.

Тебе для того, чтобы забрать текст по хттп нужен зоопарк хттп клиентов? Нет. Почему для гуя он должен быть обязательно?

Тем более что в вебне это зоопарк уже есть

Я не рассматриваю то, что там рисуют в вебне и какие у веб-макак там либы. Я говорю тебе про хттп, а не про браузер. Нахер ты его сюда приплёл?

Любое из этого тут не поможет, вася наваяет на php а маша на ноде, и будешь ставить и то и другое.

Ты вообще нихера не понял походу.

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

Тебе для того, чтобы забрать текст по хттп нужен зоопарк хттп клиентов?

Каких клиентов? Я про сервер. Зоопарк серверов будет.

Я не рассматриваю то, что там рисуют в вебне и какие у веб-макак там либы.

Причем тут рисование? На бэкенде зоопарк. Ты про то как на бэкенде все, в курсе вообще?

Ты вообще нихера не понял походу.

Конечно не понял, ты внятно объяснить ничего не можешь. Самый главный у меня вопрос - зачем мне твой мусорный http в прикладухе? Что это дает? Он и в вебне скоро станет не нужен.

James_Holden ()
Ответ на: комментарий от reprimand

Т.е. слака с sbo колонизировала луну? Круто, чо.

Stanson ★★★★★ ()

Какой странный опрос.

Какой вектор развития дистрибуции и пакетирования пользовательских программ вы считаете наиболее интересным и/или перспективным

nix и порты к пользовательским программам имеют не больше отношения чем любой другой пакетный мнеджер, которых в опросе вообще нет. Т.е. есть вариант «Другой», но зачем из него особо выделять nix и порты? И по результатам уже вижу что опрос из-за этого стал бесполезным. Фанаты nix голосуют за nix не читая/не осознавая вопрос.

Проголосовал за flatpak на том основании что оперативка на десктопах чуть менее резиновая чем принято считать, особенно если несколько жирных приложений (браузер, GIMP, Blender) запускать одновременно.

Gentooshnik ★★★★ ()
Ответ на: комментарий от James_Holden

Каких клиентов? Я про сервер. Зоопарк серверов будет.

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

На бэкенде зоопарк. Ты про то как на бэкенде все, в курсе вообще?

Вообще не про это речь. Совсем. Тебя несёт не в ту степь.

Конечно не понял

Вот тут нихера удивительного нет.

ты внятно объяснить ничего не можешь.

Это сложно, когда говоришь про протокол, а тебе начинают втирать про фреймворки на беке, браузер, вебню и то, что там скоро будет не нужно. Я не могу тебя бить по голове, каждый раз, когда ты начинаешь собирать всякую херню.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Конечно было трудно понять, но я вроде вкурил о чем ты.

Чтобы был один стандартный протокол, и тогда становится по барабану какой конкретно бэкенд - протокол то один и тот же.

Так что ли?

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

Теперь возьмем линукс. Тут мы имеем протокол иксов, он даже сетевой. Позволяет рисовать примитивами в окне. Как-бы тоже все есть уже. Только, во-первых, никто его напрямую не использует, поверх него работает тулкит. А во-вторых, в итоге по соображениям производительности все перешло к отказу от возможностей протокола в плане рисования, и приложение просто заливает готовую, уже нарисованную картинку в X сервер.

Ты предлагаешь в этом плане сделать шаг назад.

То есть - в итоге мы видим, что и в линуксе, и в винде изначально есть стандартный протокол для GUI, но реальность такова, что он используется через тучу оберток. Почему ты думаешь что твои идеи как-то кардинально от этого отличаются?

James_Holden ()
Ответ на: комментарий от crutch_master

Поясню подробнее про прикладуху.

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

То есть, как идет процесс создания GUI.

Любой GUI сложнее чем окно с кнопкой строится из своих компонентов, созданных под задачу. То есть ты берешь стандартные компонеты из тулкита, и путем наследования или композиции создаешь свои компоненты. Потом из них собирается содержимое окна.

В протокол ты это не засунешь - потому что в каждом приложении такие компоненты свои. Должна быть возможность их создавать.

Именно поэтому поверх стандартного протокола X сервера применяются тулкиты. Именно поэтому в веб-фронтенде туча фреймворков и недостаточно голого DOM API.

Твой протокол в итоге будет низкоуровневым, и будет все равно требоваться либо тулкит, либо свои обертки внутри самого проекта.

И для прикладника тогда теряется профит в наличии стандартного протокола - все равно он будет работать через обертки. Все равно надо тащить фреймворк который позволяет городить эти обертки.

James_Holden ()
Ответ на: комментарий от James_Holden

Маладец, все правильно написал.

Пользователю нужны именно приложения, а требовательному пользователю - нужны приложения вполне конкретных версий. Просто потому, что самая актуальная версия приложения не значит более лучшая. Часто в актуальных версиях разломано то, что работало в более старых. Поэтому пользователь должен иметь возможность устанавливать любое пользовательское приложение любой версии без оглядки на библиотечное окружение.

Xintrea ★★★★★ ()

Не очень понял суть вопроса, но проголосовал за статическую линковку и BSD, потому что всё остальное явно не годится вообще никуда.

И не нашёл пункта «обычные пакетные менеджеры ОС».

По поводу appimage и прочих «соберём мусор в чёрный ящик»: если вы всё равно не собираетесь обновлять отдельные компоненты приложения, просто линкуйте его статически, скачивать придётся один файл и работать он будет везде, безо всяких мутных обёрток.

firkax ()
Ответ на: комментарий от James_Holden

Позволяет рисовать примитивами в окне. Как-бы тоже все есть уже. Только, во-первых, никто его напрямую не использует, поверх него работает тулкит. А во-вторых, в итоге по соображениям производительности все перешло к отказу от возможностей протокола в плане рисования, и приложение просто заливает готовую, уже нарисованную картинку в X сервер.

Причём тут производительность? Она как раз наоборот страдает от такого. А если ещё и подключение по сети (а значит - недоступно расширение XShm) то производительность страдает на порядки.

firkax ()
Ответ на: комментарий от firkax

если вы всё равно не собираетесь обновлять отдельные компоненты приложения

Почему это не собираемся. Во flatpak как раз собираемся.

James_Holden ()
Ответ на: комментарий от firkax

Причём тут производительность? Она как раз наоборот страдает от такого.

Каким образом она страдает? Отрендерить картинку внутри приложения будет быстрее, чем дергая протокол иксов. Особенно если там что-то сложнее линий и квадратиков.

А если ещё и подключение по сети

Да, в этом случае так. Но это никому не надо.

James_Holden ()
Ответ на: комментарий от James_Holden

Зависит от задач. Но вообще да, я тут подумал и пришёл к выводу, что в текущем состоянии дел почти всё рассчитано на передачу картинок. А те приложения, которые могли бы эффективно использовать векторный X протокол, сейчас обычно используют векторный «протокол» html (со всем сопутствующим) в браузере. Хотя мне что-то это засилье веба везде не нравится.

firkax ()

Интерпретатор с скоростью асемблера, с запуском файла в один клик. Но пока такого не придумали. А пока nix

shpinog ★★★ ()
Последнее исправление: shpinog (всего исправлений: 1)
Ответ на: комментарий от James_Holden

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

Угу. В сеть запихнуть всё что надо смогли, а гуйня - это непроходимо сложна.

Любой GUI сложнее чем окно с кнопкой строится из своих компонентов, созданных под задачу. То есть ты берешь стандартные компонеты из тулкита, и путем наследования или композиции создаешь свои компоненты.

Много ты видел сильно видоизменённых компонентном? Наследуют мышевозы обычно формочки, потому что у них так тулкит гуя сделан, а так - большинство всего - дефолтное. Сейчас пооткрывал используемую гуйню - всё дефолтное. В скайпе только кнопки круглые и всё.

Именно поэтому поверх стандартного протокола X сервера применяются тулкиты. Именно поэтому в веб-фронтенде туча фреймворков и недостаточно голого DOM API.

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

И для прикладника тогда теряется профит в наличии стандартного протокола - все равно он будет работать через обертки. Все равно надо тащить фреймворк который позволяет городить эти обертки.

Ну, если бы писал ты, то очевидно затащил бы всякого мусора, завязанного на конкретной версии либц, чтобы нарисовать круг через тупейшее api.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от James_Holden

только договориться тут будет сложно, потому что профит от этого не очень явный

С вебчиком получилось и профит вполне явный. Тем, кто ломает протокол и пропихивает вендорлок - ссать на тупые рожи и бить палками.

Ты предлагаешь в этом плане сделать шаг назад.

Ну ок, сейчас везде пихают цсс с разметкой, объясни пацанам, что они делают шаг взад.

То есть - в итоге мы видим, что и в линуксе, и в винде изначально есть стандартный протокол для GUI, но реальность такова, что он используется через тучу оберток

Реальность такова, что на фоне этого всего начал взлетать электрон, лул. Да, там тупо браузер и один «протокол» для рисования гуя/взаимодействия с хостом. Если бы браузер «хостился» на платформе, это отчасти бы решало проблемы жира. Так-то реализация говёная и избыточная, конечно, но хоть что-то.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)

изменения ради изменений - это не прогресс. сначала нужно определить, что не устраивает в существующих решениях и тогда станет понятно, что нужно менять, а не устраивать очередной холивар.

dummy ★★ ()
Ответ на: комментарий от crutch_master

В сеть запихнуть всё что надо смогли

Ты ничего не понял. Видимо ты представление о том как внутри устроен GUI имеешь крайне смутное. Отсюда твои проблемы. Тебе кажется, что твоя идея - это круто а прикладники дурачки лишь потому что ты не понимаешь как это все разрабатывается и как работает. Опыта такого нет, и это очевидно по дальнейшим ответам.

Много ты видел сильно видоизменённых компонентном?

Вот яркий пример. Ты даже не понял зачем создавать свои компоненты. Причем тут видоизменение. Если бы ты писал софт, то понимал бы. Свои компоненты создают для инкапсуляции, а не для видоизменения. А без инкапсуляции ты очень быстро утонешь, твой код в лапшу превратится сразу. Яркий пример - JQuery.

То есть то что ты не видишь нестандартно выглядящих компонентов и делаешь вывод, что там нафигачено все прямо на компонентах из тулкита, это о многом говорит.

Ты сравниваешь жопу с пальцем

Нет, просто ты не понял того что я написал. Перечитай еще раз до просветления, зачем тулкиты поверх протокола иксов и поверх DOM API, если все рисовать можно на голом протоколе иксов. И тем более на DOM API.

Ну, если бы писал ты, то очевидно затащил бы всякого мусора

А ты у нас много GUI написал? По видимому, ничего. Но тебе виднее как надо, ага.

С вебчиком получилось и профит вполне явный

Что получилось? Ты вообще представляешь себе как браузер работает? Я вижу что нет. Хотя ты же на ноде что-то там ваяешь вроде, должен что-то понимать.

По твоему «вебовскому» протоколу передается приложение в браузер. А не команды отрисовки! Далее, это приложение, будучи запущено в браузере локально, через DOM API рисует что-то. Это ничем не отличается от десктопной прикладухи, кроме языка на котором все написано.

То есть http на практике сейчас используется:

  1. Для передачи тебе приложения-фронтенда.

  2. Для передачи данных.

  3. Для передачи html - документа, если надо по старинке.

Для передачи команд отрисовки оно не используется. Ну так кто там о чем договорился? Там в итоге наоборот все пришло к схеме, которая была на десктопе.

начал взлетать электрон, лул

Вот именно что лул. Ты похоже и как электрон работает тоже не понимаешь. Приложение на электроне не использует никакой сетевой протокол для отрисовки, оно использует электрон как обычный тулкит для GUI. Использует DOM API прямо внутри виртуальной машины. Это ничем не отличается от замены электрона на Qt с QWebEngine в окне. Это просто очередной фреймворк.

James_Holden ()
Ответ на: комментарий от James_Holden

Вот яркий пример. Ты даже не понял зачем создавать свои компоненты. Причем тут видоизменение. Если бы ты писал софт, то понимал бы. Свои компоненты создают для инкапсуляции, а не для видоизменения.

Это про то, когда херачат код прямо в обработчик?

Далее, это приложение, будучи запущено в браузере локально, через DOM API рисует что-то. Это ничем не отличается от десктопной прикладухи, кроме языка на котором все написано.

А еще кроме того, что есть стандарт этого самого dom, который отвязан от реализации. А еще есть стандарт js, который тоже отвязан от реализации.

Приложение на электроне не использует никакой сетевой протокол для отрисовки

Я в курсе. Потому что у електрона один хост - одно приложение. Нахера ему протокол? У браузера - одна вкладка - одна страница/вебапп. А теперь тебе, гений, вопрос что мешает сделать document сетевым?

Это ничем не отличается от замены электрона на Qt с QWebEngine в окне.

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

crutch_master ★★★★★ ()
Ответ на: комментарий от Gentooshnik

Проголосовал за flatpak на том основании что оперативка на десктопах чуть менее резиновая чем принято считать

А Flatpak тут причём? На практике всё равно шиш будет и больше ОЗУ.

fornlr ★★★★★ ()
Ответ на: комментарий от crutch_master

Это про то, когда херачат код прямо в обработчик?

Нет. Это когда ты создаешь свой компонент, внутри него несколько стандартных. Панель какая-то например. Блок где несколько кнопок, несколько полей для ввода. Внутри такого компонента реализуется внутренняя логика, которая наружу уже не торчит и изолирована от всего остального что будет в окне.

Потом из набора таких компонентов делается уже все содержимое окна.

Если делать не так, то у тебя все бухнется в общую кашу.

А еще кроме того, что есть стандарт этого самого dom, который отвязан от реализации

Это да, преимущество. Но это не протокол типа http, это та же библиотека со своим API. То есть мы можем сказать - а давай сделаем стандартный, например сишный, API для всех систем. Условно - как WinAPI и Wine. Разные реализации, один API. Только сделаем нормально. С тем что это хорошо я не спорю. Мне осталось понять, почему ты напираешь именно на протокол «типа http», а не на библиотеку со стандартным API.

А теперь тебе, гений, вопрос что мешает сделать document сетевым?

Я все равно в деталях не могу понять что ты хочешь. Что значит «сетевой document»? DOM на сервере, и оттуда по сети на клиент идут команды что отрисовывать на экране?

Тогда ты X протокол переизобрел. Только там сервер и клиент меняются местами.

переписывание на другой тулкит нетривиально

Ты не можешь все равно понять, что в браузере у тебя стандартный только низкоуровневый API, типа WinAPI. Да, он стандартный, но напрямую веб-приложения его не используют, а тянут такие же фреймворки. И переписывание веб-приложения с одного фреймворка на другой еще менее тривиально чем на десктопе.

У тебя какое-то ложное представление, что в вебне все стандартно и все в протоколе, потому что тебе не надо ставить браузер под каждый сайт.

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

Преимущество веб платформы тут только в том, что низкоуровневая часть стандартна, а в линуксе, при скачивании Qt на лету ты легко можешь огрести от несовместимости даже libc.

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

James_Holden ()
Ответ на: комментарий от crutch_master

А по поводу электрона - там настолько все стандартизировано что каждое приложение тянет свою версию электрона, и обновление тянет еще версии.

Вот спроси, сколько электронов в системе? У меня вот столько:

local/electron 13.1.6-1
    Build cross platform desktop apps with web technologies
local/electron2 2.0.18-4
    Build cross platform desktop apps with web technologies
local/electron4 4.2.12-6
    Build cross platform desktop apps with web technologies
local/electron5 5.0.13-7
    Build cross platform desktop apps with web technologies
local/electron6 6.1.12-6
    Build cross platform desktop apps with web technologies
local/electron7 7.1.14-7
    Build cross platform desktop apps with web technologies
local/electron9 9.4.4-1
    Build cross platform desktop apps with web technologies

И это не считая того что в Flatpak.

То есть здравые идеи, которые ты высказываешь, на практике оказываются вот этим.

По факту стандартизации нигде сейчас нет, ни в прикладухе, ни в вебе, ни в электроне.

James_Holden ()
Ответ на: комментарий от Gentooshnik

Ну я про вариант с бородатыми репами сравнивал…

А если с этими сравнивать, то трудно сказать. Я вот что-то не уверен…

Скорее всего жирный вариант с тупым .tar.go без всего это трах-бабаха победит над Flatpak.

Опять же не надо верить в волшебные 🪄 палочки, которые всё сделают в лучшем виде.

https://github.com/flatpak/flatpak/issues/984

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 3)
Ответ на: комментарий от fornlr

Скорее всего жирный вариант с тупым .tar.go без всего это трах-бабаха победит над Flatpak.

Да, я лично не вижу ни одной причины почему Flatpak должен жрать меньше. А учитывая что он, в отличие от tar.gz вообще системных библиотек не использует - наверняка будет жрать больше.

На практике, на своих 4 Гб ОЗУ я разницы с обычными пакетами не ощущаю. По ачучениям, а не по замерам.

James_Holden ()
Последнее исправление: James_Holden (всего исправлений: 1)
Ответ на: комментарий от Gentooshnik

Вот по ссылке @fornlr хороший четкий ответ:

The kernel will only avoid in-ram duplication if the file is the same inode. This is true for library files shared between apps and runtimes in a single flatpak installation (i.e. all –user, or all –system installs). However, it will not be shared with libraries that are on the host, even if the files happen to be identical.

James_Holden ()
Ответ на: комментарий от mord0d

ещё в восьмидесятые, если не в семидесятые.

Да, помню в 74 году скачал с интернета порты и компилял, так и было.

shpinog ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.