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

Если ты слепой

А почему у вас тут одни токсики на форуме?

то их как минимум 4 миллиона

Мне кто-нибудь из этих фанатиков всего официального объяснит, как Pale Moon поставить?

А где это объяснено? Несовместимости чего с чем? В разных дистрах что в одной и той же либе функции по-разному называются? Просто ведь драйвера пользователь ставит с учетом кривизны своего железа, возможно из исходников, возможно патченные, и как бы это не разработчика приложения дело. У меня например Android Emulator используется с -accel on -gpu host -use-system-libs, без этого не помню, что будет, но не пойдет. Если нельзя написать программу так, чтобы ей было пофигу на компе с какой видеокартой она выполняется, то что-то с этим не так.

на рабочем компе он у меня архивом лежит в хомяке, дома собран с сорцов

Несовместимости чего с чем?

libc в системе, и в твоем пакете.

В разных дистрах что в одной и той же либе функции по-разному называются?

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

и как бы это не разработчика приложения дело

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

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

Промежуточные варианты всегда будут страдать от несовместимости библиотек «внутри» и «снаружи».

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

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

В разных дистрах что в одной и той же либе функции по-разному называются

Именно так. В одном дистре pow@@GLIBC_2.29, а в другом pow@@GLIBC_2.2.5, с поправкой на то, что 2.2.5 есть на обоих, но слинковаться софт может с 2.29

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

Потому что популярный софт, но тащить телеметрию и прочую бяку не стесняется.

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

Наконец-то дошло зачем нужен AppImage/Flatpak?

Отказываются поддерживать технологию, которая лично вам не нравится — «всё правильно делают»

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

В иксах всей этой фигни нет.

В основном .deb, редко .appimage. Никаких flatpak и snap.

Можете мне объяснить, а то я в танке походу. glibc имеет обратную совместимость, то есть программа, собранная на glibc версии N будет работать на glibc N + k с вероятностью 99.9%. Почему бы не собирать бинарники на старых libc? Не обязательно же сборку в арче проводить, можно например в Debian 10.

А просто архив?

Кстати, а чем тебе AppImage не просто архив? Берем бинарник, кладём вместе с ним либы + монтирование архива через fuse - получаешь AppImage.

Ну в принципе AppImage архив, но не совсем, он libfuse требует. Ну а если его распаковать - то да, отличий не будет. Не сильно понимаю, зачем нужен fuse, когда можно просто tar + zstd.

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

Snap 56 (17%)

Кто все эти люди и что они делают тут?

А разве у вейланда нет стабильного протокола?

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

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

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

Должны быть единые реализации всех фич

Есть же wlroots, если все перейдут на его использование, то проблема скорее всего будет решена. А пока что три велосипеда - KDE, GNOME и все остальные с wlroots.

У иксов тоже протокол один. Только из всех его реализаций всего одна вменяемая - Xorg. Остальные сделаны в основном для совместимости или Just for fun.

Как раз-таки наоборот: единый протокол позволяет без проблем иметь несколько взаимозаменяемых реализаций.

При условии что есть единая реализация. В иксах это работает, в Wayland-е нет.

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

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

А пока что три велосипеда - KDE, GNOME и все остальные с wlroots.

Велосипедов гораздо больше, только пара WM по факту юзают wlroots.

Биоректор уже не тот

Есть же реализация иксов для макоси.

Appimage нормально: запустил - работает, закрыл - закрылся. А вот snap прямо бесит. Эта гадость такую кипучую деятельность развивает - какие-то демоны, монтирует/демонтирует кучу всяких дисков, какие-то левые директории в хомяке и в /run/user. А уж файрфокс в снапе - это вообще нечто. Тормозит, выдаёт неотключаемые уведомления, ставит меня на счётчик («осталось 13 дней»). Короче, буду валить с убунты.

Уф, высказался :-)

Есть, но как я уже написал, сделано для совместимости. Так то XWayland тоже реализация.

Короче, буду валить с убунты.

Не надо было и заходить.

Убунта в свои лучшие годы была прекрасным дистрибутивом. К сожалению, это в прошлом.

Добро пожаловать к нам на Манжару, например. :)

Их и собирают на старых. Но например, мое приложение использует новые либы, само по себе, и собрать его на дебиане 10 проблема.

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

Если прога использует новые версии либ - то она и не должна работать на старых системах. Многие проги от win10 не работают на win7. Тем более в libc почти ничего не меняется в API, чтобы был смысл завязываться на новые версии. А всё остальное(не libc, в том числе и libstdc++) можно таскать с собой или линковать статически.

Тоже. Ну или в виде git clone.

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

Как раз-таки наоборот: единый протокол позволяет без проблем иметь несколько взаимозаменяемых реализаций.

При условии что есть единая реализация

Вы вообще понимаете, что такое протокол? Не нужна единая реализация для того чтобы программа работала под всеми композиторами — нужен единый протокол и его поддержка нужными композиторами. Всё.

snap, appimage, flatpak лол. Хотелось оставить только флатпак, но не удается, некоторые приложения разработчик поставляет только в снапе, а разные неофициальные перепаковки не интересуют.

И libc тоже не надо таскать с собой.

Вы вообще понимаете, что такое протокол? Не нужна единая реализация для того чтобы программа работала под всеми композиторами — нужен единый протокол и его поддержка нужными композиторами. Всё.

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

Протокол - это тупо скелет, на него можно навернуть любые фичи. Без фич Wayland не нужен.

Согласен, не надо. Это тоже то, что я и пытался вдолбить непробиваемому probono, автору AppImage.

Осталось собирать всё на какой-нибудь шестой центоси. :)

snap, appimage, flatpak лол. Хотелось оставить только флатпак, но не удается, некоторые приложения разработчик поставляет только в снапе, а разные неофициальные перепаковки не интересуют.

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

Это какие? На ум только LXD приходит и тот потому что Canonical пишет. Дебиановцы, слава Селестии, осилили его пересобрать в deb.

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

Они ориентируются на убунту, а там снап из коробки. Но это уже шаг вперед по сравнению с тарболами и скачиванием deb.

Это какие?

IDE от JetBrains, slack, spotify, да хватает.

Потому что популярный софт, но тащить телеметрию и прочую бяку не стесняется.

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

Думаю примерно также как заставить авторов каждого мелкого или среднего проекта выпускать говноблобы. Наконец-то дошло зачем нужен AppImage/Flatpak?

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

• В отличии от единственного автора (ты же за то чтобы говноблобы делали авторы, иначе это те же мантейнеры которых, по-твоему, «не заставишь» и которые «пропадают»), мантейнеров много, поэтому если не опакетит автор то пакета не будет. Если не опакетит или отвалится один мантейнер, придёт другой.
• У мантейнеров есть экспертиза в опакечивании, поэтому пакет они сделают качественно. Автор не умеет, или намеренно делает как хочется ему, а не как нужно пользователю, в том числе с точки зрения интеграции в систему. Хотя какой интеграции можно ожидать от говноблобов, ещё и с изоляцией, которые даже темы не подхватывают…
• Не опакечивание не тратится драгоценное время автора (всех авторов).
• Используется инфраструктура дистрибутива, например сборка под кучу архитектур. Много ты видел говноблобов сразу подо все архитектуры, поддерживаемые хотя бы сраным дебианом? Да хоть под M1?
• Пакеты прозрачны - все видят что коммитится в репу, значит там меньше вероятность ошибок и малвари.
• Пакеты пригодны к модификации, значит пользователь может настроить их под себя как штатным (типа USE-флагов/FreeBSD OPTIONS) способом, так и модификацией рецепта сборки.

Список можно продолжать но мне лень.

А в AppImage ее разве таскают с собой? Не рекомендуется же в спецификации.

Они ориентируются на убунту, а там снап из коробки.

Удалить и поставить Flatpak?

А. Ну я не из этих, не пользуюсь. :)

Тогда почему в вяленде запись экрана через костыли?

Нет там никаких костылей. Используется PipeWire как мультимедиа-фреймворк, в который композитор «кладёт» кадры.

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

Почему DE в вяленде не совместимы между собой?

Ещё раз, по буквам: нужен единый протокол и его поддержка композиторами. Там, где композиторы поддерживают общий протокол, никаких несовместимостей за пределами багов не существует.

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

У AppImage нет спецификации на такое.

Потому что сам по себе AppImage это просто формат из простого загрузчика, который через внешний libfuse (и что им мешает просто через сисколлы работать?) монтирует squashfs образ внутри. По факту они изобрели SFX.

А вот как собирать программу чтобы она работала на большинстве дистрибутивов – это сугубо ваше дело.

У AppImage нет спецификации на такое.

А это что? https://github.com/AppImageCommunity/pkg2appimage/blob/master/excludelist

Все это есть на флатхабе.

Все это есть на флатхабе.

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

Snap, потому что выбора нет с этим фуррифоксом. Ёжик ел убунту, кололся, плакал и т.д.