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 ()
Последнее исправление: fernandos (всего исправлений: 3)

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

Да. Тут у меня любимый пример был с Telegram, который тянул гигабайт рантаймов с GNOME, и гигабайт рантаймов с KDE. Не знаю, как это на ОЗУ влияло.

Ну и само собой, что и сами эти рантаймы одинаковыми не будут.

Вот есть у тебя тройка приложений — одно будет с GNOMe 3.32, другое с 3.34, другое с 4.0. А у тебя ОС стоит с 3.36.

Ещё если у тебя Nvidia (судя по нику нет), то тот же Flatpak тебе ещё и специальный рантайм для Nvidia притащит.

Ну и расходы на сам flatpak тоже надо добавлять.

То есть в реальности это только добавит жира, а не уменьшит.

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

Ок, значит надо проверять на практике.

Ещё если у тебя Nvidia (судя по нику нет)

У меня была нвидия. Ужасно глючила. Переставил в соседскую винду - ТОЖЕ ГЛЮЧИТ. >_< Теперь AMD.

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

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

Тебе какая разница, где у тебя крутится модель, в кишках гуя или где-то отдельно и так же изолировано?

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

Ну да, там каждый сайт тащит свой кутэ, месу, иксы, а потом всё это долго компиляется.

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

Это - не полный аналог. Ты сравниваешь жопу с пальцем.

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

Охереть, до тебя дошло.

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

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

Не спорю о том, что электрон - кусок говна.

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

Проблемы прикладников-формошлёпов, которые ничего не могут.

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

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

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

Тебе какая разница, где у тебя крутится модель

Какая модель? Модель в схеме MVC - это база данных, грубо говоря, а я говорю про View.

Но да, если ты предоставишь стандартный низкоуровневый протокол для команд отрисовки, то она может крутиться отдельно. Как это с X сервером происходит фактически. Только вот эта концепция (протокола исков) накрылась медным тазом. Почему это - все дурачки?

Ну да, там каждый сайт тащит свой кутэ, месу, иксы, а потом всё это долго компиляется.

Меса и иксы то тут причем? Иксы даже флатпак не тащит.

А Qt да, считай что каждый сайт тащит. И потом оно довольно долго компилируется в браузере, ты не знал?

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

Это - не полный аналог.

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

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

Да. Теперь тебе осталось понять, почему так происходит.

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

Я считаю наиболее перспективным текущее положение дел в виде родных пакетов (deb/rpm/etc) с учётом эволюционного развития без разрушения инфраструктуры с достойной и полной обратной совместимостью в рамках разумного или полностью если последнее никак не повлияет на внесение разумных новшеств. Этот вариант стыдливо спрятали в «Другое» что по моему важному мнению (лол) достойно порицания. Я всё сказал. Одновременно с этим также на уровне родных пакетов должны поддерживаться самодостаточные приложения уровня appimage где во главе переносимость и прозрачность, а не переусложнённая инфраструктура с сомнительной и довольно бесполезной попыткой контроля приложений. Для этого должны быть явные политики на уровне системы и регулирующие механизмы тчк

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от MOPKOBKA

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

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Я считаю наиболее перспективным текущее положение дел в виде родных пакетов (deb/rpm/etc)

Этот зоопарк тормозит развитие. Разработчику должен быть предоставлен удобный (для него самого и конечного пользователя) метод пакетирования и дистрибуции программ.

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

А Qt да, считай что каждый сайт тащит. И потом оно довольно долго компилируется в браузере, ты не знал?

Ага. Так долго, что можно на ночь оставить.

К тому же, тянуть Qt в виде исходников и компилировать никто не стал бы, тянулась бы бинарная версия.

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

Нет, это то же самое.

Нет, не тоже, ибо dom и браузерные апи, а не рисование руками кругов на opengl, сборка нативщины + связанные с этим проблемы и переизобретание вообще всего. Вот зделают тебе wasm будешь там круги и формочки на кутэ свои рисовать и рассказывать. У тебя аргументы, «кроме кококо, ты ничё на знаешь, кококо, кутэ и вебчик - это одно и тоже!!!11» еще будут?

Да. Теперь тебе осталось понять, почему так происходит.

Давай свою тупую версию и закончим на этом.

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

Этот зоопарк тормозит развитие.

Новые механизмы лишь плодят зоопарк, нужно развитие, а не революции

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

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

и конечного пользователя

command --install appname одинаково для всех. Сделать command --install appname --version xxx yyy zzz не составит труда в уже имеющихся условиях без изобретения кардинально новых решений ломающих всё ради пары тройки своих особенностей.

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

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Новые механизмы лишь плодят зоопарк, нужно развитие, а не революции

Нет, если они унифицируют формат пакетов и взаимодействие с ними. Что и делает флатпак/снап.

Должен и предоставляется

Ага, спасибо кроссдистрибутивным системам работы с пакетами.

command –install appname одинаково для всех

Или не для всех. А ещё, если отойти от мейнстримных дистрибутивов, то репозитории не вмещают все необходимые программы, тут удобно иметь что-то одно, что-то универсальное.

Сделать command –install appname –version xxx yyy zzz не составит труда в уже имеющихся условиях без изобретения кардинально новых решений ломающих всё ради пары тройки своих особенностей

Никто не станет хранить все (или просто большое их количество) версии пакетов, прийдётся использовать что-то типа пэкэджбилда.

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

Нет, если они унифицируют формат пакетов и взаимодействие с ними. Что и делает флатпак/снап.

Два абсолютно несовместимых друга никакой унификации не несут. Будут нести если будут единственными в рамках дистрибутивов. Но только 1. Сейчас как выше уже было сказанно просто в зоопарке родились ещё зверьки.

Ага, спасибо кроссдистрибутивным системам работы с пакетами.

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

Никто не станет хранить все (или просто большое их количество) версии пакетов, придётся использовать что-то типа пэкэджбилда.

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

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

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от LINUX-ORG-RU

Два абсолютно несовместимых друга никакой унификации не несут

Несут. Пока они банально конкурируют, а вот когда (так-то уже) одно решение победит другое — вот вам стандарт.

Будут нести если будут единственными в рамках дистрибутивов

Вот тогда-то будет зоопарк.

Сейчас как выше уже было сказанно просто в зоопарке родились ещё зверьки

Эти ваши зверьки уже лучше остальных, они универсальны, а один зверёк уже начинает кушать других.

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

Вот когда случится, тогда и поговорим. Никто не гарантирует что компания [ДАННЫЕ ЗАСЕКРЕЧЕНЫ] просто анонсирует [ЦЕНЗУРА] проект который станет массово продвигаться в том числе [ДАННЫЕ ЗАСЕКРЕЧЕНЫ],[ДАННЫЕ ЗАСЕКРЕЧЕНЫ],[ДАННЫЕ ЗАСЕКРЕЧЕНЫ] и другими как нечто общее. И будет ещё один конкурирующий… формат и сопутствующие механизмы.

А пока, имеем что имеем.

Эти ваши зверьки уже лучше остальных

Спорно. Очень спорно. Но на этом лично я закончу.

LINUX-ORG-RU ★★★★★
()

Невозможно ответить, потому что есть разные задачи. Что-то можно написать на PWA, что-то завернуть во flatpak, а что-то добавить в репозиторий. Все варианты, кроме PWA, не кроссплатформенные - вот, что действительно важно. BSD это отдельный смех, юзеры так и мечтают денно и ночно компилировать на своих ноутбуках.

Кроссплатформенные варианты перспективней, здесь это PWA. Но есть ещё всякие монстры вроде flutter. А как там распространять - не так уж важно, главное, что один код работает везде, как в Java. Для линукса перспективней будет старый вариант репозиториев, чтобы не зависить от левых приложений.

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

Так долго, что можно на ночь оставить.

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

Еще раз - для тех кто в танке. Нативщина у тебя вообще не компилируется, ты ее получаешь уже в бинарном виде. То есть компиляция займет не ночь, а ровно 0 секунд. Быстрее у тебя никакой js не сможет.

Рядом с которой надо собирать дистрибутив

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

до 50мб

Правильно. И нативщина весит 30-50 Мб, если делать полностью самодостаточный пакет, с Qt и всеми либами. Больше она будет весить, если там не-GUI часть тяжелая. В вебне у тебя не-GUI часть на бэкенде, ты ее не видишь, и как я раньше писал делаешь вывод что ее нет. Как страус.

Если озаботиться размером то легко можно и в 10 Мб уложиться. То есть нативщина по размеру совершенно сопоставима с js веб-приложением на фреймворках.

Вот зделают тебе wasm будешь там круги и формочки на кутэ свои рисовать и рассказывать

Так и сделают, я тебе о чем и говорю. Это неизбежное будущее вебни. По мере усложнения GUI всегда идет движение в этом направлении. В нативщине это произошло лет 15 назад, в вебе происходит сейчас. И никакого «протокола» в твоем понимании там скоро вообще не будет.

У тебя аргументы, «кроме кококо, ты ничё на знаешь, кококо, кутэ и вебчик - это одно и тоже!!!11» еще будут?

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

Давай свою тупую версию и закончим на этом.

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

Как происходила эволюция GUI. На нативщине -

  1. был стандартный протокол X сервера, в винде - WinAPI.

  2. По мере усложнения GUI протокол X сервера оброс тучей расширений и потонул, WinAPI обросло тучей расширений и превратилось в месиво.

  3. Все пришли к тому что низкоуровневый «протокол» должен позволять лишь залить полностью готовую картинку окна на сервер. А все внутри должно рисоваться внутри приложения как ему удобнее. Это произошло лет 10 назад как минимум.

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

Теперь - как развивался веб интерфейс.

  1. Сначала вообще все было на HTML с веб формами. Вообще все по стандарту.

  2. По мере усложнения GUI добавили интерактивность, и все обросло тучей js оберток, например JQuery.

  3. При дальнейшем усложнении GUI код на JQuery стал нечитаемой неподдерживаемой лапшой. И появились тяжелые фреймворки и рендеринг на клиенте (а не на сервере как раньше). То есть GUI стало отрисовывать локально запущенное веб-приложение, пока еще используя стандартный DOM API.

  4. Для того чтобы по 3 этапу делать все более сложный GUI, DOM API раздули до чудовищной толстоты, и браузеры просто начали тонуть под тяжестью развесистого API, который никто кроме гугла не осиливает уже реализовать. Все браузерные движки подохли, остался хромиум, куда вливают сотни нефти. По сложности хромиум давно превзошел ОС и все нативные фреймворки вместе взятые.

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

То есть - был протокол и нет протокола.

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

Нет, если они унифицируют формат пакетов и взаимодействие с ними. Что и делает флатпак/снап

Как 2 несовместимых решения могут что-то унифицировать? Не кажется ли тебе что пока не будет одного для всех дистрибутивов (а его не будет никогда) то разговор об унификации больше похож на неудачную шутку?

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

Как 2 несовместимых решения могут что-то унифицировать

Убирают необходимость в зоопарке.

Не кажется ли тебе что пока не будет одного для всех дистрибутивов (а его не будет никогда) то разговор об унификации больше похож на неудачную шутку

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

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

Убирают необходимость в зоопарке.

Это уже мемом стало.

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

Интерпретатор с скоростью асемблера

Лисп машины сдохли(

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

Но есть и хорошие новости: в отличие от реального мира, проектироващикам систем можно сидеть на обоих стульях одновременно и это не западло.

thesis ★★★★★
()

лень читать все 6 страниц…

софт ставить дисками (А,AP,X обычно хватало рядовому деятелю), зависимости рулить чтением манов, а далее

configure ; make ; sudo make install

уже озвучен единственно верный способ ? :-) в опрос он отчего-то не вошёл..

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

Главное - в такой среде нет приложений. В юникс-вее их даже так и не называют, а называют утилиты. На самом деле это функции для языка shell или библиотеки функций.

Шта?? У тебя база данных - это функция для шелла? Или веб-сервер?

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

Развитие этих сфер. Допустим, кроссдистрибутивная система портов.

надо сначала разделить на opensource и closesource

opensource можно и просто собрать (хотя через оверлеи удобнее =) ).

всякие флэтснапшмяки для свободных программ зло.

проприетарщина пусть дистрибутирует как хочет, за это им деньги платят

samy_volosaty ★★★★★
()

RPM/DEB/tar.gz с зависимостью от довольно-таки старого Glibc, но при этом скомпилировано новым компилятором.

ZenitharChampion ★★★★★
()

А где вариант «я до сих пор компиляю сорцы слаки и курю ганджубас»?

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

У тебя база данных - это функция для шелла? Или веб-сервер?

Еще один. Конечно, так и есть. Только не функция, а библиотека функций.

Как работает веб-сервер, ты в курсе? Например, мы посылаем GET запрос. Это что, не функция? А что тогда, кастрюля?

Любой запрос к веб серверу - это вызов функции. То есть веб сервер это библиотека функций.

Для чего - для шелла? Прежде всего для браузера, то есть веб клиента. Если надо для шелла - man curl, вот тебе и для шелла.

Про СУБД (база данных - это файл с данными, лол, конечно это не функция, поэтому видимо ты имел в виду СУБД), и про то что такое SQL объяснять надо? Думаю уже должно быть понятно и так.

James_Holden ★★★
()

Для разных задач и пользователей по разному.

  1. Классический ПМ (например apt)
  2. Сборка из исходников (LFS). Использую его, но понимаю, что не все знают файлы всех пакетов и могут управлять ими вручную.
DMITRY
()
Ответ на: комментарий от James_Holden

Еще один. Конечно, так и есть. Только не функция, а библиотека функций.

Ага. То есть, веб-сервер, запущенный под Linux - это библоиотека функций, а веб-сервер, запущенный под Windows - это что? Приложение? Или библиотека функций?

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

Ты вообще ничего не понял.

Перечитай мой первый пост.

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

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

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

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

Или ты проводишь границы по тому, взаимодействует пользователь с чем-то напрямую, или через какого-то клиента? Но тогда при чем тут ОС?

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

Или ты проводишь границы по тому, взаимодействует пользователь с чем-то напрямую, или через какого-то клиента?

Почти, но не совсем.

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

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

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

James_Holden ★★★
()

Родная репа дистрибутива. Всё остальное - сплошной вред.

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

Я понял, твою логику, но не понял, при чем тут ОС. Пайплайны умеют строить все интерпретаторы. ЕМНИП, даже WinBatch.

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

Дело не в ОС, понятно что в любой можно делать и то и то.

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

А теперь это осталось как наследие и оно продолжает влиять.

James_Holden ★★★
()

А где Snap?

Блин, снова три формата: AppImage, FlatPack и Snap. И каким должен пользоваться прикладной программист для распространения софта под Linux?

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

А где Snap?

Дело не в реализации.

Блин, снова три формата: AppImage, FlatPack и Snap. И каким должен пользоваться прикладной программист для распространения софта под Linux

Флатпак или статическая линковка

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

Не решение.

Ну да, не решение, поэтому или она, или флатпак.

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