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 ()

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

Это несколько про другое. Хотя может подходить и под п.1 (и даже п.2), так как это приведёт к унификации формата приложений, что приведёт к централизации (хотя и неполной). Но не думаю, что будет достигнута «единая система».

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

Это несколько про другое.

BSD именно как software distribution, а не как цельная ОС, вполне себе «дистрибуция и пакетирование».

Порты — это отлаженная система доставки кода конечному пользователю. Порты, являясь частью ОС, не делают частью ОС "портированный" софт.

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

Система портов так-то уже есть — портаж

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

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

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

уже есть

уже

Но да, идея взята у портов. ;)

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

Идём дальше! ☺

Пакеты всё-в-одном вначале появились в Mac OS X (на тот момент ещё не macOS), и только после идея была растащена Appimage, Flatpak, Snap (в какой последовательности — не знаю).

И даже systemd — попытка сделать подобие launchd(8) из Mac OS X.

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

Я вам больше скажу PWA — те же веб страницы, просто у таких приложений есть дополнительные права и возможности.

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

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

Слишком маловероятно. Так и будет куча форматов пакетов, которые привязаны к дистрибутиву.

К слову, вы же корректор, можете корректировать.

fernandos ★★★ ()

интересным и/или перспективным

Тут тогда нужен мультивыбор. Потому как:

Кроссдистрибутивные системы управления пакетами (flatpak)
Создание пакетов «всё-в-одном» (appimage)
Кроссплатформенные веб-приложения (PWA, wasm)

перспективно, но неинтересно

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

интересно, но бесперспективно

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

не является «развитем», поскольку известно со времён царя Гороха.

А вообще я тут недавно хотел сделать zim-файл из дампа одной вики и впервые познал все прелести NodeJS и этой их приблуды, которая типа пакетный менеджер. Думал, повешусь.
Лучше уж статическая линковка и помойка в /opt.

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

Тут тогда нужен мультивыбор

Есть, спасибо.

не является «развитем», поскольку известно со времён царя Гороха.

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

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

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

интересно, но бесперспективно

Можно раскрыть тему. На мой взгляд выглядит перспективно. Давно пользуюсь guix в виртуалке, обновил систему через год простоя и удивился что она осталась в рабочем состоянии. Если такое проделать с арчем например, будет скорее всего грустное зрелище…

torm7 ()

Я так понимаю обычные пакетники это «другое»? Потому что перспективность не в методе запаковки, а втом, насколько удачно и качественно это сделано.

kirill_rrr ★★★★★ ()

Ух сколько провисело.

Голосую за флатпак конечно.

Почему так - не постесняюсь повторить в очередной раз.

Сначала нужно понять вот это:

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

Примеры систем первого типа - винда, андроид, мак.

Примеры систем второго типа - юникс-вей системы: линукс (тот который все тут любят, классический) и бсд.

То есть главное различие то в чем! В юникс-вее среда разработки это и есть система. Дальше все строится на этом принципе. Отсюда - консоль, потому что это интерпретатор! Не для того чтобы вы страдали и красноглазили вам в линуксы воткнули консоль, а она там по той простой причине, что линукс - это изначально среда программирования, в консоли - на языках shell, bash и так далее.

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

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

Именно поэтому они так хороши для:

  1. Серверов

  2. Установки библиотек для C/C++, да и для скриптовых языков.

  3. Организации среды разработки, например установки всех зависимостей библиотек под какой-либо проект.

Именно поэтому появилась такая штука как пакетные менеджеры языков. Чтобы кроссдистрибутивно и кроссплатформенно решать задачу установки библиотек.

Но!!!!! Для пользовательской системы это не подходит. А пользовательская система это что? Это там, где мы не разрабатываем, а используем готовые приложения. Приложение - от слов «прикладная задача»! То есть это то, что решает прикладную, мать ее через колено, задачу!! А не общая функция из библиотеки (утилита юникс вея).

Любому дураку, кроме лоровца, далее понятно, что ставить приложения через механизм для установки библиотек… как бы корретнее сказать… субоптимально!

Поэтому - если мы хотим видеть линукс как пользовательскую систему, а не среду разработки растянутую на всю систему, мы должны поддерживать эволюцию средств дистрибуции ПРИЛОЖЕНИЙ, а не пакетов с библиотеками и утилитами.

Сейчас это - флатпак, снап, с натяжкой AppImage. Nix сюда ни в какие ворота не лезет, он оперирует теми же понятиями библиотек, а не приложений, и для десктопа он не пригоден вообще!

James_Holden ()

где очевидный вариант «ЭОС»

seras ()

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

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

Что мешает разбить пакеты другим, более оптимальным образом, реорганизовать корень, переделать зависимости, перелопатить и переподключить репы, написать новые скрипты установки/удаления?

Мультиархитектурные системы и пользовательские ppa появились вполне себе в рамках того же самого deb-пакета. И это куда больше и важнее чем появление флатпака и прочего.

В конце концов ни один флатпак ещё не дорос до своего логичного завершения: полностью автономного образа виртуальной машины, заточенного под одно приложения, но многие системы виртуализации и со стандартизованными (и удобными!) интерфейсами связи с внешним миром.

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

Flatpak - классная вещь. Если он когда-нибудь сравнится по количеству пакетов с AUR, цены ему не будет.

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

разбить пакеты другим, более оптимальным образом

Что значит «разбить пакеты»?

реорганизовать корень

ЛФС. Пакеты тут ни при чём.

переделать зависимости

Каким образом переделать?

перелопатить и переподключить репы

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

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

Зачем вообще это делать? Может оптимизировать саму установку/загрузку/удаление? Дык уже есть такие практики.

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

Это не его логичное завершение.

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

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

kirill_rrr ★★★★★ ()

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

Флатпак всё равно является больше вариантом условного «докера», а не нормального самодостаточного пакета.

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

Что значит «разбить пакеты»?

Ну, можно просто запаковать вайн в пакет «вайн» и положить в репу. А можно запаковать вайн в пакеты вайн-1, вайн 1.1, вайн-2… и все их положить в репу, причём так, что они не будут конфликтовать. И тут обычно не нужен nix. Или можно положить один единственный пакет с офисом или разбить его на 20+ отдельных, например вынеся плагины и локали. Или вместо одного пакета vi можно сделать виртуальный пакет vi, ссылающийся на одну из ~5 различных реализаций. Тонны вариантов.

ЛФС. Пакеты тут ни при чём.

Мне казалось этот стандарт уже не в почёте и все кто мог от него уже отказались. А ещё мне кажется, что всё тем же deb-пакетом можно и андроид, и винду и макось запаковать, и мне кажется получится получше оригинала.

Каким образом переделать?

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

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

Если взять свалку пакетов и реорганизовать её так, чтобы стало удобно пользоваться это вполне себе развитие. Только скучное, без революциий.

Может оптимизировать саму установку/загрузку/удаление?

Это одно и то же. Потому что в остальном пакетный менеджер просто распаковывает архив и всё.

Это не его логичное завершение.

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

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

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

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

Nix ценен разве что этой фичой, в Nix неправильно сразу всё остальное

починил, не благодари :)

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

А можно запаковать вайн в пакеты вайн-1, вайн 1.1, вайн-2… и все их положить в репу, причём так, что они не будут конфликтовать

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

Или можно положить один единственный пакет с офисом или разбить его на 20+ отдельных, например вынеся плагины и локали

Так уже делают. А плагины к либре устанавливаются из файлов.

Мне казалось этот стандарт уже не в почёте и все кто мог от него уже отказались

Вам кажется. В гоболинуксе сломали ЛФС, и где он сейчас.

Больше или меньше зависимостей

Использовать лишь необходимые для работы зависимости? А остальные вынести в опциональные.

Если взять свалку пакетов и реорганизовать её так, чтобы стало удобно пользоваться это вполне себе развитие

Какую ещё свалку? Вот в арче или генте свалка?

Потому что в остальном пакетный менеджер просто распаковывает архив и всё

Или не просто распаковывает, или ещё вообще не распаковывает, а монтирует образ.

А жаль

Вы вообще можете представить, сколько бы весил образ виртуальной машины? Сколько бы он занимал памяти?

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

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

Да, полностью согласен с этим.

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

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

но в андроиде приложения сами по себе и совершенно не могут работать совместно

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

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

Флатпак всё равно является больше вариантом условного «докера», а не нормального самодостаточного пакета.

У флатпака в этом плане есть фатальный недостаток - сложности с организацией простого переносимого руками файла-инсталлятора приложения. И его не исправить - это следствие из завязки на OSTree.

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

Или вместо одного пакета vi можно сделать виртуальный пакет vi, ссылающийся на одну из ~5 различных реализаций. Тонны вариантов.

Это ровно то о чем я писал - такой подход хорош для библиотек, но не подходит для приложений.

Для приложений должна быть система - 1 пакет == 1 приложение. Причем весьма желательно, чтобы этот пакет был файлом который можно носить оффлайн.

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

Конечно, это можно настроить (а может и нет, кто знает, что там автор придумал), но это неудобно.

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

В гоболинуксе сломали ЛФС

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

Использовать лишь необходимые для работы зависимости? А остальные вынести в опциональные.

Казалось бы, это же очевидно. Но почему никто так не делает?

Какую ещё свалку?

В void например свалка, а в генте неплохо структурировано. Но мне кажется что можно ещё лучше.

Вы вообще можете представить, сколько бы весил образ виртуальной машины? Сколько бы он занимал памяти?

Да, могу. У меня старые игрушки, мс-офис и компас-график запакованы в виртуалку со сдутой винХП. Оверхед порядка 300м места на диске и 150М памяти на штуку, это от двух раз до порядка эффективней электрона. Но винХП не славится способностью к построению минималистичных окружений, какой нибудь альпин мог бы делать всё то же, только компактней. А вот если бы ещё как то не дублировать функции ядра и драйверов…

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

Не могут, а теоретически могут. На практике всё взаимодействие заканчивается тем, что одно приложение вызывает системный диалог открытия файла, а диалог уже строит список приложений на выбор. Никаких find | grep | vlc, вызываемых по кнопке с панели или хоткею. Даже единого диалога открытия/сохранения файлов нет.

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

Так вроде в федоре и убунту тоже сломали. снап и флатпак вообще в принципе его ломает

Не в таком глобальном плане.

образы монтируются куда то

Только снап.

Но почему никто так не делает

Арч, гента — никто?

альпин

А паковать будут не в альпин, а в целую убунту.

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

Никаких find | grep | vlc, вызываемых по кнопке с панели или хоткею.

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

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

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

снап и флатпак вообще в принципе его ломает

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

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

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

Если не ошибаюсь, порты появились где-то году в 1993-м… Линуксы… если не ошибаюсь, года эдак с 1992. Не?

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

Для приложений должна быть система - 1 пакет == 1 приложение.

Тогда получится прибитое гвоздями хрен пойми что. Вот например любое приложение в системе может потребовать открыть гиперссылку. А где открыть? В единственном возможном браузере, или в неком виртуальном универсальном браузере, который ссылается на один из ~20 браузеров из репы? У каждого более-менее типового инструмента должно быть несколько вариантов и система выбора.

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

пайпы - уже инструмент среды разработки.

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

kirill_rrr ★★★★★ ()

Исполняемый код будет подгружаться с онлайна, кэш храниться локально. Или стриминг.

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

А паковать будут не в альпин, а в целую убунту.

Вопросы реализации. Любой хороший проект можно запороть в процессе реализации.

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

Тогда получится прибитое гвоздями хрен пойми что

Почему получится, так устроены все системы кроме линукса. Да и линукс уже почти такой. Как-то же работает все.

Вот например любое приложение в системе может потребовать открыть гиперссылку

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

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

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

автоматизации пользовательской рутины

Автоматизация это и есть разработка, вообще-то.

Просто от пользователя чуть больше требуется

Ну да, требуется программировать. Кто же спорит, что умея программировать, перед тобой раздвигаются горизонты.

Только вот никто не умеет почти.

James_Holden ()

Проголосовал за AppImage как способ, наименее ломающий существующую систему.

В целом меня устраивает установка прикладного ПО из репозиториев дистрибутивов, это обеспечивает унификацию, мне не нравится, когда каждая программа тащит в систему свою копию, например, libxml2. Но иногда нужны свежие версии программ, например, видеоредакторов. Вот тут на помощь приходит AppImage.

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

Проголосовал за AppImage как способ, наименее ломающий существующую систему.

Он ломает так же как и все остальное, потому что если я устанавливаю программы как AppImage, то пакеты уже не нужны. Остаются нужными только пакеты с базовыми компонентами системы.

То же самое и со Snap, и с Flatpak.

мне не нравится, когда каждая программа тащит в систему свою копию, например, libxml2

И поэтому голосуешь за AppImage который, в отличие от Flatpak, именно так и делает?

И что, например, ломает в системе Flatpak? Он никак не мешает остальной системе.

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

Если не ошибаюсь, порты появились где-то году в 1993-м

В привычном виде они появились в FreeBSD в 1993. Но до этого была похожая система (хотя дерево исходников ОС и софта было общим) в других UNIX-like ещё в восьмидесятые, если не в семидесятые.

Линуксы… если не ошибаюсь, года эдак с 1992

В 1991.

Тем не менее, при создании portage, в Gentoo смотрели именно на систему портов FreeBSD. Не только название системы распространения схоже, но и название и назначение некоторых утилит (например etc-update в Gentoo, etcupdate во FreeBSD).

mord0d ★★★★★ ()
Последнее исправление: mord0d (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.