В мире технологий есть старая шутка о том, что каждый раз, когда кто-то пытается создать формат, который объединяет все лучшее, чтобы избежать разброса, они только добавляют новый в список. Отчасти это связано с попытками создать формат пакета, который может работать во всех дистрибутивах Linux без изменений. Пока в этом веке нас уже было трое.
Snap, Flatpak и Appimage. Отличия от традиционных форматов
Основное различие между собственными форматами пакетов и автономными форматами пакетов состоит в том, что первые разделяют зависимости с другими программами, установленными в операционной системе. Другими словами, если программе Y нужна зависимость 1 и эта зависимость была установлена программой X, которая также нуждается в ней, эта зависимость не будет установлена снова.
Программы, упакованные в отдельные форматы, включают все зависимости, которые им необходимы для работы. Другими словами, зависимость 1 будет устанавливаться каждый раз при установке программы, которая в ней нуждается.
Второе отличие состоит в том, что традиционные форматы пакетов должны создаваться с учетом спецификаций каждого дистрибутива.. Вот почему, хотя Ubuntu является дистрибутивом, производным от Debian, различия настолько важны, что репозитории первого не могут использоваться во втором.
Третье отличие состоит в том, что любое изменение зависимости от традиционных пакетов может повлиять на работу всех остальных, которым это необходимо. С другой стороны, изменения программы в независимом формате не повлияют на остальную часть системы.
В зависимости от особенностей каждого дистрибутива можно установить приложения в независимых форматах из диспетчера пакетов и автоматизировать их обновление с помощью диспетчера, отвечающего за них.
В Ubuntu Центр программного обеспечения позволяет устанавливать обе программы в традиционных форматах, таких как Snap, отдавая предпочтение последнему. Несмотря на то, что есть плагин, позволяющий использовать Центр программного обеспечения GNOME (от которого произошел Ubuntu), он не работает с этим дистрибутивом.
В случае Ubuntu Studio можно включить возможность использования пакетов Snap, в то время как KDE Neon и Manjaro могут работать с обоими форматами.
Снэп
Это новейший из независимых форматов с момента его разработки в 2014 году. Он предназначен не только для использования в настольных дистрибутивах Linux, но и для Интернета вещей, мобильных устройств и серверов. КХотя можно создавать отдельные магазины приложений, в настоящее время существует только один, управляемый Canonical, Снапкрафт.
Хотя в Snapcraft есть набор самых популярных приложений с открытым исходным кодом, Его сильная сторона - программы, разработанные частными разработчиками программного обеспечения и поставщиками облачных услуг.
Flatpak
Хотя Flatpak официально запущен в 2015 году, он является продолжением другого проекта универсального формата, известного как xdg-app. Этот проект родился с целью иметь возможность запускать приложения в безопасной виртуальной песочнице, которая не требует привилегий root и не представляет угрозы для безопасности системы.
Flatpak ориентирован на настольные дистрибутивы, а также использует концепцию магазина приложений. Flathub самый известный.
Сильная сторона Flathub в том, что обычно у него самые последние версии основных приложений с открытым исходным кодом.
AppImage
AppImage - самый старый из форматов автономных пакетов, поскольку он был впервые выпущен в 2004 году.
Это был первый формат, следовавший парадигме «Одно приложение - один файл».. Это означает, что каждый раз, когда мы загружаем файл Appimage, мы загружаем приложение и все, что ему нужно для работы. Если мы хотим использовать приложение, нам просто нужно предоставить ему разрешения на выполнение и дважды щелкнуть значок, который его идентифицирует.
Appimage не использует систему магазина приложений, но, там веб-страница в котором мы можем найти список всех доступных названий.
Чтобы обновить Appimage, мы можем использовать этот инструмент.
Я скучаю по тому, что не было упоминания о чрезвычайно медленном увеличении скорости привязки при установке приложений, потому что для каждого из них требуется виртуальный блок.
Я скучаю по тому, что не было упоминания о чрезвычайно медленном увеличении скорости привязки при установке приложений, потому что для каждого из них требуется виртуальный блок.
Спасибо за ваш комментарий. Я буду иметь это в виду.
Лично я считаю, что проблемы независимой упаковки программного обеспечения - не что иное, как отражение гораздо более глубокого конфликта, который связан со степенью соответствия стандартам LSB и FSH различными дистрибутивами.
Одна из основных составляющих упаковки - это реализация стандартных библиотек, сохраняющих как место, так и расположение программного обеспечения, а также файлы конфигурации. Таким образом, избегая конфликтов библиотек. То, что характерно для других операционных систем и что, к сожалению, из-за несоответствия стандартам, в конечном итоге затрудняет обслуживание и обновление программного обеспечения, не говоря уже о переносе программного обеспечения из одного дистрибутива в другой. Плохая практика ручной компиляции, выполняемая много раз из инструкции, без анализа соответствия стандартам при ее реализации, в конечном итоге становится огромной головной болью для системных администраторов. Особенно, когда кто-то должен взять на себя производственный сервер, установленный другим предыдущим администратором.
Независимая упаковка, так или иначе, вносит свой вклад в эту философию, продвигая нечто большее, чем независимость, зависимость от определенного формата или компании. Много раз сделать миграцию платформы практически невыполнимой задачей. Думать больше в краткосрочной перспективе, чем в долгосрочной. Ситуация, свидетелем которой может стать любой серьезный админ с опытом работы более 15 лет. И я говорю эту цифру специально, так как за этот период пройдет достаточно распространений, чтобы понять, что рано или поздно проекты или службы будут вынуждены по той или иной причине перейти с платформы. Ситуация, которая редко попадает в процессы оценки при реализации проекта. Легче всего перенести именно те платформы, которые лучше всего соответствуют вышеупомянутым стандартам. Эти независимые пакеты наиболее далеки от этих стандартов.
Интересный вклад, мне и в голову не пришло подумать об этом
Инструмент обновления файлов AppImage практически бесполезен. Из 7 файлов AppImage, которые я пробовал (Inkscape, Olive, KSnip, MuseScore, OpenShot среди других), он пытался работать только с одним, заканчиваясь сообщением «Нет проверочной подписи» и, следовательно, не обновлял его. То есть, ЭТО НИКОМУ НЕ ИСПОЛЬЗУЕТСЯ, ссылку можно удалить. Кроме того, он не обновлялся несколько месяцев.
Спасибо за комментарий