Какими «самодостаточными» форматами пакетов вы пользуетесь?

Все эмуляторы на Flatpak. Удобно.

И репаки от Кроника через скрипт или архив

Остальное репы, на арче и так все свежее.

Тем более wine точно не стабилен, программа может работать на 7.10 и перестать на 8.0

Обычно только если программа лезет в слишком узкоспецифичные вещи вроде дотнетов

Так если не залезать в мутные части glibc, тоже ничего не ломается.

Совместимость совместимостью, но glibc в дебианах не хотят обновлять, при этом там постоянно бампают версии символов для каких-то базовых функций.
Тащить glibc с собой? Ну притащил ты glibc с собой, ок. Пытаешься загиузить i965_dri.so из системы, а он зависит от более нового glibc и либо вообще не загрузится, либо что похуже. У меня так когда-то steam runtime типа «работал», только при взрыве гранаты в hl2 она зависала. Решалось отключением рантайма. Сейчас поправили и рантайм выбирает более новую версию.
Загрузить же несколько версий параллельно не выйдет - они будут спотыкаться о символы друг друга, мало того, можно нпткнуться на несовместимость каких-нибудь шаренных структур. Тут нужны какие-то неймспейсы. Но тут может быть конфликт в реализации TLS

Ломается. Недавно сломали pow. То есть что угодно что использует возведение в степень перестало запускаться на дебианах будучи собранным на чём-то другом

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

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

обратная совместимость в порядке, но отсутствие прямой даже для самых базовых вещей делает это всё непригодным. Софт линкуют с системным libc, а не с каким-нибудь generic glibc sdk, специально сделанным с учётом популярных версий, при этом в дебианах несмотря на отсутствие каких-либо побочных эффектов (кроме очень редко поднимающейся минимальной версии ядра) glibc не обновляют, при этом ещё умудряясь обновлять софт. Почему не держать самую свежую libc не понятно

Аппимедж дал Флатпаку по морде? Вотетапаварот... Так насильно пропихиваемый «стандарт» уступил «неправильному» предшественнику, над которым ржут красношапкососы. Мир всё-таки не полностью просран, роботы подождите ещё.

Использую из перечисленных только Flatpak. Потому что:

1. Пакеты от сторонних разработчиков часто такой звиздец в скриптах имеют, что аж страшно. До сих пор вспоминаю howdy, который в postinst-скрипте скачивал и компилировал стороннюю библиотеку. Позволять запускать это всё, да ещё и с правами root, – спасибо, но нет.

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

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

4. В отличие от AppImage, нормально прописывается в системе, единообразно обновляется и проч.

5. Всякое проприетарное ПО, к которому доверия нет от слова «совсем» (Anydesk, Skype, Discord…), изолировано от системы в песочнице, которую можно легко и просто огородить ещё сильнее (или, наоборот, разрешить ходить куда-нибудь) через Flatseal.

Под мою FreeBSD этого рака, к счастью, нет.

Большого кол-ва пользователей и приложений тоже. В FreeBSD это всё не нужно!

Под Linux не пользовался бы ни при каких условиях.

«Настоящие посоны с большими пиписьками компиляют систему и приложения из исходников в отличии от быдла!»

Большого кол-ва пользователей и приложений тоже. В FreeBSD это всё не нужно!

Не просто абстрактно большего, а конкретно проприетарщины и её пользователей. Да, не нужно - также как и в Linux.

«Настоящие посоны с большими пиписьками компиляют систему и приложения из исходников в отличии от быдла!»

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

Юзаю Flatpak и AppImage когда как. Flatpak/AppImage позволяет ставить приложения не засирая основную систему. Если есть deb, юзаю deb. Проблема у обоих в том, что они плохо подхватывают системные настройки (темы, шрифты, file picker-ы и так далее). AppImage не работает по сети (ssh -X). А так в целом даже круче чем в винде.

Не просто абстрактно большего, а конкретно проприетарщины и её пользователей.

Вот благодаря таким как ты Linux и не выйдет в массы и так и будет считаться маргинальщиной с низкой поддержкой железа. А так можно было бы привлечь больше пользователей в разработку СПО за счёт большей популярности. К тому же, лучше качественная проприетарщина, чем GNOMEсофт.

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

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

Сценарий-установщик от производителя программы

Кстати, сценарии-установщики бывают и не от производителя программы. Например, в альте есть epm, который содержит набор скриптов для установки популярного ПО. Тот же Google Chrome там ставится как epm play chrome — этой командой скрипт скачает с сайта гугла rpm-ник под федору, перепакует, установит зависимости и какие-то конфиги и даже будет обновлять в будущем.

Понятно, что этот скрипт писали не в Google.

есть хороший шанс, что проголосовавшие за «deb или rpm, в который сборщик включил все зависимости» не поняли вопроса

А вообще, почему не таскать с собой свою libc?

Это невозможно.

Ну точнее возможно, но очень ограниченно. Например, никакого вам OpenGL. Это я в своё время и пытался вдолбить автору AppImage, что притащить драйвер с собой он не сможет (банально потому что их вариаций великое множество, не говоря уже о версиях). Уж понял ли этот кадр что-то я не знаю, но AppImage сам по себе как ни решал НИ ОДНУ проблему создания кроссдистрибутивных программ, так и не решает. Он даже до сих пор зависит на внешнем libfuse.

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

УМВР. Лор-эффект?

Почему докер не в списке?

Сейчас всё образами докера распространяют…

Я теперь тоже так думаю. :((( Надо было написать «все используемые библиотеки».

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

Даже если проиграет процент-два, то я всё равно рад. Хотя, понимая тенденции, всё равно же шапка продавит эту гадость в умы хомяков.

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

Прямо мои мысли 1 в 1. Пока, как арчешкольник, юзаю AUR для проприетарщины и того, что нет в репах, но подумываю накатить в систему именно Flatpak.

Flatpak

В отличие от AppImage, нормально прописывается в системе, единообразно обновляется и проч.

AppImage тоже может нормально прописываться в системе. Что до единообразного обновления, то для прикладных программ это может быть как достоинством, так и недостатком.

Хорошо, я ЗАПУСКАЛ Kdenlive из AppImage.

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

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

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

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

Никакими

Вот благодаря таким как ты Linux и не выйдет в массы и так и будет считаться маргинальщиной с низкой поддержкой железа. А так можно было бы привлечь больше пользователей в разработку СПО за счёт большей популярности. К тому же, лучше качественная проприетарщина, чем GNOMEсофт.

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

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

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

ebuild

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

Так распространяются некоторые проприетарные программы для Linux, например, Яндекс.Браузер

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

Да дело не в pe тут, а в том, что в винде winapi и libc разделён

А у нас в Лялипсе получается нет какого-то аналога winapi?

И нельзя смешивать разные libc

А часто ли это бывает нужно? Почему нельзя указать в системных требованиях типа «нужна libc такая-то или новее»?

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

Ставил из этих форматов телегу, формат не помню и winbox из flatpak. Последний - крохотный .exe для которого флатпак подтянул аж 1,5 гига зависимостей. Я не выдержал это созерцать и запускаю wine64 ./winbox.exe. Работает без проблем.

можно из родных пакетов

Которых нет.

Это я в своё время и пытался вдолбить автору AppImage, что притащить драйвер с собой он не сможет

А зачем тащить с собой драйвера? Это же часть системы.

AppImage/Snap

AppImage тоже может нормально прописываться в системе

Как это сделать для всех пользователей в системе?

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

И в чём же недостатки? Если что, речь не идёт об автоматических обновлениях.

С AppImage возникают ещё вопросы к адекватности некоторых из её основных разработчиков, которые переносят свои личные отношения к технологиям на всех. Как пример, товарищ probonopd с его отношением к Wayland:

Thanks, but I am not interested in Wayland. None of my systems run Wayland, because it never works quite right in my experience.

Code change looks reasonable … Remains the philosophical question:

Should we really help promoting the splintering of the *nix desktop by shipping Wayland-specific stuff?

Ему отправили нормальный (по его же словам) pull request, но у него лапки личный experience. А завтра ему ещё что-нибудь не понравится.

А у нас в Лялипсе получается нет какого-то аналога winapi?

Есть - wine.

Как будто wine весит меньше полутора гигов.

Если ты слепой, то их как минимум 4 миллиона, при том что repology считает source пакеты в основном. На flathub (при том что flatpak, судя по опросу, самый популярный из тройки flatpak/snap/appimage), например, всего 2 тысячи.

А зачем тащить с собой драйвера? Это же часть системы.

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

в Лялипсе получается нет какого-то аналога winapi?

Wine API.

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

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

На Firefox посмотри сначала, ага. Вот твой хвалёный опен-соурс во всей красе.

Разработчики не опакечивают свой софт, его опакечивают мантейнеры.

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

Ты ох*еешь что таким способом опакечены сотни тысяч проектов под сотни дистрибутивов при том что авторы вообще пальцем не пошевелили.

А потом эти мейнтейнеры уходят в закат и до свидания.

С AppImage возникают ещё вопросы к адекватности некоторых из её основных разработчиков, которые переносят свои личные отношения к технологиям на всех. Как пример, товарищ probonopd с его отношением к Wayland:

Всё правильно делает. К таким говноподелкам только так.

Да, вместо него glibc, который имеет одностороннюю совместимость, и syscall api ядра, который конечно стабилен, но не имеет средств даже для загрузки библиотек. Без libc ты не загрузишь libGL, потому тебе придётся прилинковаться к libc, который совместим с тем, с которым слинкован libGL. Либо же тащишь свой libGL с собой, который не будет способен поддерживать аппаратное ускорение везде. Даже если притащишь mesa целиком, привет от того, что этой версией mesa не поддерживается или плохо поддерживается.
Я уже тут делал несколько описаний возможных решений этой проблемы:
Один бинарник на четыре системы (комментарий)
Netscape Navigator 9 в Debian 11 (комментарий)

На Firefox посмотри сначала, ага. Вот твой хвалёный опен-соурс во всей красе.

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

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

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

Всё правильно делает. К таким говноподелкам только так.

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