Какие форматы распространения программ вам НЕ нравятся?

Классические пакеты

99% софта именно в них. Благодаря обширным репозиториям арча и AUR.

Flatpak/Snap

Ненужное ненужно

AppImage

В принципе нормально, но пакет всё-таки лучше. Своё я бы паковал именно в него (ну или в архив).

Архив с установочным скриптом

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

Архив с исходниками

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

Ну и не хватает варианта «портабельный архив» (почти всё проприетарное распространяется именно таким образом).

Классические пакеты - наше всё. Архивы качаю, когда версия в репах не устраивает или софтины в репах вовсе нет.

Flatpak/Snap/AppImage тоже нужны, но то, как они используются - квинтэссенция зла. Разработчикам Telegram лень собрать хотя бы DEB и RPM для миллионов пользователей (нас даже на онтопике миллионы) - в итоге Telegram валяется где угодно (обычно в ~/Downloads) и оттуда же прописывается в автозагрузку. Ubuntu насильно впихивает Snap, притягивая его через зависимости apt. Почему? Потому что мейнтейнерам лень по-человечески пакет собрать, а жёсткий диск у юзеров резиновый.

Хоть флатпаком не сильно злоупотребляют - и то хорошо.

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

Жаль, что опрос удалят, потому что был недавно такой. О пакетах можно говорить бесконечно. hobbit, перенеси, что ли, в Лолксы.

Архив с установочным скриптом

Не разу не сталкивался

Ну как же? Распаковываешь архив - а там файло и install.sh. Или только install.sh, который файло или из сети тянет, или внутри себя в base64 содержит.

Ну и не хватает варианта «портабельный архив»

Это как? Вот бывает, что архив с файлом install.sh, так распространяются к примеру продукты VMware и IntelliJ IDEA

А вот установщик отдельным файлом встречается

Он что ли запускаемый? А какого тогда формата? Я вот искал, чисто ради любопытства, какой формат исполняемых файлов в линукс (как .exe в винде), но что-то так ничего и не понял

Есть ещё софт, распространяемый в виде контейнеров docker/lxc.

А ещё софт, распространяемый через pip/npm/cpan/etc.

Обычно такой установщик представляет собой shell-скрипт, где основной бинарный код упакован в base64.

1. Классические пакеты (в т.ч. npm, pip…)

   Нужно! Потому что Flatpak может не всё. И не-системные пакетные менеджеры нужны, что бы не заниматься некрофилией и не завязываться на одну ОС. Актуально для фронтенда, например.

2. Flatpak/Snap

   Нужно! Сэндбоксинг - это комильфо, и данные таких приложений проще переносить между системами, т.к. они хранятся в одном месте. Шнап, кстати, не нужен. Потому что убунту-центричен и централизован. Рефы флатпака, как и классические репы, могут быть откуда угодно.

3. AppImage

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

4. Установочный скрипт/архив с ним

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

5. Docker/LCX

   Нужно! Наконец-то можно не гадить в корень системы, а гонять проекты в контейнере!

6. Архив с исходниками

   Не нужно. Барабанил я в рот что-то собирать руками, если оно есть в запакованном виде. Я слишком стар для этого. А если даже придётся, предпочту клон из git-а, нежели архивы.

Сделал мультивыбор

Смотря каких программ. В идеале:

• Для опенсорса: классические пакеты (только что за убогие примеры в скобках? Где .pkg.tar.zst, .deb, .rpm) + исходники.
• Для проприетарщины: AppImage или аналог.

Flatpak/Snap — ненужное ненужно.

Docker нужен, но не как способ распространения софта.

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

Архив со скриптом запуска (не установки, это лишнее, хочешь ставить в систему - собирай пакет, в хомяк же пользователь сам распакует)

Предлагаю немного поменять заглавный вопрос:

Какие форматы распространения программ Вам не нравятся больше всего?

Flatpak/Snap

Разбить на 2 варианта, тут многие нейтрально относятся к flatpak, но большинство не переносит snap

Docker/LCX

Тоже разбить, lxc это больше про «легковестные виртуалки», а не распространение чего-либо.

только что за убогие примеры в скобках?

Там ключевые слова – «в том числе»

Nick: MrCookie
ID: 206000

Прикольно

Какая вкуснота, глаза разбегаются.

НЕ нравятся?

Все, кроме классических пакетов.

Что ты несёшь, пакеты и npm-ный мусор в один пункт объединять?

.exe, .msi, .msix и .appx :)

Тогда уж и .dmg надо добавить.

✔ Flatpak

✔ Snap

✔ Программа установки/установочный скрипт

✔ Docker (С каких пор это формат распространения программ?)

✔ LXC (тем более)

✔ npm, pip и прочие не системные ПМ

✔ .exe, .msi, .msix и .appx :)

Короче, рулят классические пакеты, исходники и AppImage. Ну или в крайнем случае просто архив с программой (так распространяются многие игры, например).

Ну и, наверное, стоит добавить вариант «Обычный архив». Либо для симметрии исходники переименовать с «Архив с исходниками» и добавить «Архив со скомпиллированной программой».

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

Где вариант «Те, которые устанавливаются мимо системного пм»?

Классические пакеты

Нужно.

Flatpak
Snap
AppImage

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

Программа установки/установочный скрипт

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

Docker
LXC

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

npm, pip

Ненужно, софтом на этом вообще стараюсь не пользоваться, один yt-dlp есть.

.exe, .msi, .msix, .appx, .dmg

Ненужно, ну тут сами понимаете.

Исходники

Нужно.

Обычный архив с двоичной сборкой

Терпимо.

Флатпак. Одни отрицательные ощущения от использования этого оверинженернутого высера

flatpak snap appimage docker npm/pip

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

snap и flatpak на помойку. Зачем софт в lxc и docker распространять не совсем понимаю.

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

pacman: 857
AUR: 3
архив со сборкой: 6

Все остальное не использую.

Мне не очень нравится докер. Но не «вообще не нравится», я понимаю, что есть случаи, когда докер очень полезен — разработка, перенос какой-то сложной серверной конфигурации. Мне не нравится, когда его используют не к месту, именно как «формат распространения программ», всё равно каких.

Мне не нравится, когда его используют не к месту, именно как «формат распространения программ», всё равно каких.

Ну не скажи. Для распространения веб приложений докер может быть очень даже полезен. Например в арче пакет pgadmin долгое время был безнадежно сломан из-за несовместимых версий питонячьих зависимостей. В конце концов его вообще выпилили из репозиториев. Поэтому приходилось использовать докер контейнер с pgadmin. Как вариант, его можно было поставить через pip и тоже все работало. Это кстати к вопросу о пользе несистемных пакетных менеджеров вроде pip или npm.

Это кстати к вопросу о пользе несистемных пакетных менеджеров вроде pip или npm.

Это это к вопросу о неадекватности питоновской версионной политики.

+100500. Тот случай, когда настолько согласен по всем пунктам, что считаю просто реакцию недостаточной.

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

Я слишком стар
пососный способ
Барабанил я в рот

Я бы сказал, что ты не стар, а скорее молод и горяч :-).

В обществе мамкиных технарей явные негативные эмоции к «неправильным» техническим решениям это нормальная норма :).

Всё устраивает, ибо «на вкус и цвет»...

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

Не понимаю откуда столько хейта к докеру. Куча софта (серверного) идеально подходит для использования в докере.

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

И таких примеров куча, особенно когда надо какие-то сервисы ставить в парах, типа qbittorrent+sonarr+radarr+какой+то индексер для них. С докером просто сохраняешь себе конфиг файл и одной командой все ставится за минуту. Такой же лёгкий перенос этого всего куда-то ещё.

Если я вижу, что пакет может устанавливаться через npm или docker (для серверного пользования), то приоритет всегда будет ко второму.

P.s. для десктопа докер не нужен

Согласен, но ответ всё-равно добавили, за что спасибо.

.zst – мой file-roller в него не умеет.

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

А dmg тут каким боком? По этой логике надо и iso добавлять

Не нравится всё, кроме классических пакетов и исходников

не нужны потому что пытаются локально подменять системный пакетный менеджер

Как что-то плохое.

Мне вот не нравится, как системные менеджеры работают с пакетами LaTeX. По сути куча нужного и ненужного лично мне объединено в огромные системные пакеты. Свежесть пакетов LaTeX из дистрибутивов тоже иногда вызывает сомнения. Скорее, системный пакетный менеджер подменяет отсутствующий специализированный и при этом справляется так себе.

Когда я впервые столкнулся с pip, тоже недоумевал: какого хрена? Но если подумать, всё правильно сделано. Мейнтейнерам дистрибутивов не нужна возня с пакетами на Python, кроме самых ходовых. Зато сообществу Python очень интересна поддержка общего репозитория. А поскольку язык не зависит от системы и платформы, всё это действительно лучше сделать один раз для всех, а не в каждом дистрибутиве отдельно.

Например в арче пакет pgadmin долгое время был безнадежно сломан из-за несовместимых версий питонячьих зависимостей.
Это кстати к вопросу о пользе несистемных пакетных менеджеров вроде pip или npm.

Это к вопросу о том, что не всегда новая версия системы/программы работает лучше чем предыдущая (если вообще работает).

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

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

тлять, выбрал те, что нравятся… надо было сформулировать вопрос иначе.

.exe это в основном «программа установки/скрипт» и не должен быть в одном ряду с .msi и остальными. Ну и конечно оффтоп :)

Свежесть пакетов LaTeX из дистрибутивов тоже иногда вызывает сомнения

Не представляю зачем там может понадобиться «свежесть», правила разметки документов за последние 20 лет вряд ли заметно менялись.

А поскольку язык не зависит от системы и платформы,

Так почти про все языки можно сказать.

всё это действительно лучше сделать один раз для всех, а не в каждом дистрибутиве отдельно.

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

Не представляю зачем там может понадобиться «свежесть», правила разметки документов за последние 20 лет вряд ли заметно менялись.

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

Самое неудобное - сорцы, конечно. Особенно, когда софтина легко собирается только на дебиане или только на шапке. Автообновление такого софта любым способом отсутствует в принципе.

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

npm, pip и прочее «для программирования» - немного рвёт мозг, как это в итоге взаимодействует с системой и штатным ПМ

Все кроме исходников и Nix-выражений.

Не представляю зачем там может понадобиться «свежесть», правила разметки документов за последние 20 лет вряд ли заметно менялись.

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

Так почти про все языки можно сказать.

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

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

Нет. Теперь уже нет. Любой дистростроитель знает свою ЦА.

npm, pip и прочее «для программирования» - немного рвёт мозг, как это в итоге взаимодействует с системой и штатным ПМ

И как оно взаимодействует с системой и штатным ПМ?