Snap или apt что лучше

Snap-пакеты в Linux. Что это и как с ними работать

Snap пакеты

Пакетная система Snap была созданная компанией Canonical и изначально появилась в дистрибутиве Ubuntu Linux. Ее смысл заключается в том, что в пакет с приложением входит полный набор компонентов, необходимых для запуска данного приложения. Такие пакеты можно устанавливать в систему не заботясь о зависимостях, так как все зависимости уже включены в пакет.

Snap пакеты также называют «снапами».

Так как идея Snap пакетов имеет множество преимуществ, снапы быстро стали популярными и теперь используются не только в Ubuntu, но и в других дистрибутивах Linux: Debian, openSUSE, Arch Linux, Gentoo, Fedora и др.

Что такое Snap-пакет

Мы привыкли устанавливать приложения из DEB и RPM пакетов. Такие пакеты содержат саму программу, но не включают зависимости, которые требуются для запуска данного приложения.

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

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

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

Установка поддержки Snap

Для управления Snap-пакетами в Linux используется демон snapd. Для его установки необходимо установить пакет — snapd.

Пользователь использует клиент snap для управления пакетами. Клиент snap входит в состав пакета snapd.

Установка поддержки Snap в Ubuntu Linux

В новых версиях Ubuntu поддержка Snap уже включена. Если это не так, то для установки Snap в Ubuntu Linux выполните команду:

sudo apt install snapd

Аналогично выполняется установка в Debian, Linux Mint, Elementary OS и других Ubuntu/Debian-based дистрибутивах.

Установка поддержки Snap в Fedora

sudo dnf install snapd sudo ln -s /var/lib/snapd/snap /snap

После установки выйдите и войдите в систему.

Установка поддержки Snap в Arch Linux

sudo yaourt -S snapd sudo systemctl enable --now snapd.socket

Работа со Snap-пакетами

Установка пакетов

Для установки пакетов используется команда snap install имя_пакета

Пример установки графического редактора GIMP из Snap-пакета:

snap install gimp

После ввода команды будет открыто окно для ввода пароля, так как требуются привилегии root-пользователя. Или используйте sudo:

sudo snap install gimp

Обновление пакетов

Для обновления пакетов используется команда snap refresh

Обновление всех установленных пакетов:

snap refresh

Обновление одного пакета:

snap refresh gimp

Удаление пакетов

Для удаления пакетов используется команда snap remove имя_пакета

snap remove gimp

Просмотр установленных пакетов

Для просмотра списка установленных пакетов используется команда snap list

snap list

Поиск пакетов

Для поиска пакетов используется команда snap find запрос

snap find gimp

Поиск выполняется не только по имени пакета, но и по описанию, поэтому можно использовать произвольный запрос:

snap find "photo editor"

Информация о пакете

Для получения информации о каком-либо пакете используется команда snap info имя_пакета

snap info gimp

Откат обновления

Если по каким-то причинам вы хотите отменить обновления, которые были выполнены над каким-либо Snap-пакетом, то можно использовать команду snap revert имя_пакета , чтобы вернуть пакет к предыдущей версии.

snap revert gimp

Временно отключить пакет

Чтобы временно отключить пакет используется команда snap disable имя_пакета

snap disable gimp

Чтобы снова сделать пакет доступным используется команда snap enable имя_пакета :

snap enable gimp

Запуск Snap-пакетов

Для запуска Snap-пакета можно использовать команду snap run имя_пакета

snap run gimp

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

Заключение

Мы кратко рассказали о том, что представляют из себя Snap-пакеты и как с ними работать. Snap-пакеты не единственные представители подобного типа пакетов в Linux. Также популярны пакеты AppImage и Flatpak.

Linux: snap vs deb

snap

Основное различие между Snap и Apt заключается в том, что apt установит в систему отдельный пакет, а Snap загрузит целый архив со всеми необходимыми компонентами и установит его в ограниченную папку, изолированную от системы.

Когда вы устанавливаете приложение с помощью Snap, вы скачиваете точный архив, созданный разработчиками для вашей архитектуры. Он был протестирован в тех же условиях и включает все зависимости. Этот архив будет извлечен в ограниченном пространстве (в чем-то он похож на приложения Docker) и имеет ограниченный доступ к операционной системе.

Разработчикам нравится использовать Snap, потому что они могут контролировать среду установки. Меньше конфликтов с другими приложениями или различными версиями зависимостей. Если это работает у разработчиков, то и в вашей системе должно работать так же. Они также могут быстрее развертывать обновления, поскольку им не нужно ждать, пока дистрибутив проверит их обновления (что может занять много времени, особенно в таких системах, как Debian, где стабильность является ключевым фактором).

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

Snap vs Apt: сравнение производительности

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

Это основное преимущество APT, если у вас ограниченное дисковое пространство (например, SD-карта на Raspberry Pi) или плохое подключение к Интернету. Пакеты меньше, и вы устанавливаете зависимости только один раз.

В других случаях это не имеет большого значения. Для примера, установим Thunderbird обоими способами. Размер пакета составляет 59 МБ, а архив Snap — 76 МБ. Это не большая разница, даже при ограниченном пространстве или плохом соединении, но со временем, когда вы устанавливаете все больше и больше приложений, разница будет более ощутимой.

Snap vs Apt: управление обновлениями

Snap и Apt по-разному обрабатывают обновления. Обновления Snaps проверяются автоматически 4 раза в день и обновляются, как только появляется новая версия. С помощью Apt системный администратор контролирует процесс обновления.

Snap — это демон (помните «d» в конце «snapd»). Таким образом, это служба работает постоянно и регулярно проверяет наличие обновлений. Вы можете немного отложить эту проверку, но не можете избежать обновления приложений. Это идеально, если вы хотите, чтобы в вашей системе всегда была установлена последняя версия.

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

Примечание: возможно установить несколько версий одного и того же приложения с помощью snap. Это не очень полезно для большинства пользователей, но разработчикам может понравиться этот вариант. Например, если вы разрабатываете расширения для Thunderbird, вы можете установить последнюю версию и последнюю бета-версию, чтобы убедиться, что ваше расширение работает на обоих, прежде чем выпускать его для всех.

Что безопаснее Snap или Apt?

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

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

snap volume

Apt установит новые пакеты в их обычные папки (например, в /etc или /opt). Мне это больше нравится, потому что, когда вы будете искать помощь в онлайн-документации, вам будет указан именно этот путь.

С точки зрения безопасности, если вы используете официальные репозитории для своего дистрибутива, вы будите в безопасности. Группа разработчиков из организации-распространителя просматривает код каждого обновления, иногда долго тестирует приложение в «бета-версии», прежде чем выпустить его. Итак, когда он, наконец, будет доступен с apt upgrade, его установка будет безопасной.

Цикл обновления более или менее длинный в зависимости от вашего дистрибутива (пример: Ubuntu работает быстро, Debian очень медленно), но в целом достаточно безопасно установить его, как только он станет доступным. Очевидно, что если вы используете сторонние репозитории или PPA, это примечание неприменимо, так как дистрибутив не имеет контроля над этими пакетами.

Если безопасность является главной проблемой, следует избегать репозиториев PPA и сторонних разработчиков. Без проверки и без контейнера — это наиболее худший из вариантов.

Snap против Apt: плюсы и минусы

Плюсы и минусы использования Snap

Плюсы	Минусы
Обновления доступны быстро.	Занять больше места на диске.
Та же среда, что и у разработчика.	Загружать дольше.
Легче для начинающих.	Расположение файлов другое.
Всегда актуально.	Нет возможности контролировать обновления.
Никаких следов в системе после удаления.	Работает не во всех дистрибутивах (например, снимки ОС RPI не отображаются в главном меню).
Никаких проблем с зависимостью.	Snap доступны не на всех архитектурах.
Может быть безопаснее, так как приложение находится в отдельном разделе.

Плюсы и минусы использования Apt

Плюсы	Минусы
Лучшая интеграция с графическим интерфейсом в целом.	Могут возникнуть трудности с поиском пакета для установки.
Легче следовать документации, так как файлы расположены по правильному пути (/etc, /var/log и т.д.).	Никаких обновлений после устаревания версии дистрибутива.
Может быть безопаснее, так как приложение проверяется разработчиком дистрибутива.	Немного сложно для начинающих/не технически подкованных пользователей.
Пользователь имеет полный контроль над процессом обновления.

Snap или Apt: что использовать?

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

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

Если стабильность системы важнее, чем наличие последней версии (особенно для серверов и рабочих компьютеров), и вы хотите убедиться, что все протестировано и одобрено, прежде чем обновлять критически важные части вашей системы, Apt, вероятно, будет лучшим выбором.

Если вы находитесь посередине, вам нужно сделать выбор или, возможно, сначала протестировать менее чувствительные приложения и посмотреть, как оно работает. Я считаю, что это немного похоже на выбор между Ubuntu и Debian. Я могу предпочесть установить Ubuntu на начальный компьютер, так как он проще в использовании, содержит последние версии приложений и т. д. вся система).

Итого

apt — установка из маленьких пакетов, вместе образующих большую и сложную систему, при этом софт может массово совместно использовать одни и те же файлы и библиотеки, благодаря чему экономится место на диске, оперативная память итд итп. Надо понимать, что apt — это пакетный менеджер для определённого вида пакетов (deb), хотя в своё время существовал вариант для rpm (может и сейчас существует, просто смысла в нём мало после появления yum).

snap — установка большого приложения со всеми зависимостями, которые никак не использует остальной софт на этом же компьютере. Отсюда тратится лишнее место на диске и в оперативной памяти. Зато никаких проблем с зависимостями, плюс snap работает в любых системах и не завязан на конкретный менеджер пакетов и собственно пакетный формат.

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

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

Почему ругают snap?

Я вчера спрашивал о минусах mint, но мне почему-то писали только о плюсах(хотя плюсы то я и сам знаю) например, самый любимый аргумент — там нет пакетного менеджера snap. почему его некоторые так не любят?

koshsky
25.06.22 13:32:26 MSK

Потому что он приносит с собой кучу мусора(использовать нормальные зависимости из официальных реп дистра — не их путь). Плюс пакеты для него пилят не ментейнеры из нормального сообщества, а не понятно кто(буквально какие-то левые люди). Были случаи, когда в опакеченных левыми людьми snap-пакетах были вредоносы.

lucentcode ★★★★★
( 25.06.22 13:36:24 MSK )

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

andytux ★★★★★
( 25.06.22 13:39:13 MSK )

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

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

Heartbreak_Kid
( 25.06.22 13:50:22 MSK )

Тогда какой пакетный менеджер использовать вместо snap?

koshsky
( 25.06.22 13:52:59 MSK ) автор топика

потому что это кусок говна

~~annerleen~~ ★★★★☆
( 25.06.22 13:54:58 MSK )
Ответ на: комментарий от koshsky 25.06.22 13:52:59 MSK

А это уже дело шестнадцатое…

andytux ★★★★★
( 25.06.22 13:55:20 MSK )

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

goingUp ★★★★★
( 25.06.22 13:57:47 MSK )
Ответ на: комментарий от koshsky 25.06.22 13:52:59 MSK

В приоритете нативный менеджер дистрибутива (apt, pacman, zypper, etc…), а уже потом AppImage и прочие Flatpakи

Heartbreak_Kid
( 25.06.22 14:03:45 MSK )

Долго стартует даже с SSD

hateWin ★★
( 25.06.22 14:16:56 MSK )

Невозможно установить конкретную версию пакета или даунгрейднуть – рутовый сервис автоматически устанавливает самую последнюю;
Очень долгий холодный старт приложени;
Проприетарный репозиторий;
Завязан на Убунту;
Уже есть независимый и свободный flatpak для GUI и docker для серверов.

~~Im_not_a_robot~~ ★★★★★
( 25.06.22 14:37:49 MSK )
Ответ на: комментарий от koshsky 25.06.22 13:52:59 MSK

Тогда какой пакетный менеджер использовать вместо snap?

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

Если другой дистрибутив, то либо из дистрибутивных репов, или, если в них нет, flatpak.

~~Im_not_a_robot~~ ★★★★★
( 25.06.22 14:39:27 MSK )
Ответ на: комментарий от Im_not_a_robot 25.06.22 14:39:27 MSK

Такое же ненужно как и снап.

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

firkax ★★★★★
( 25.06.22 20:45:53 MSK )

Потому что программы в Snap занимают больше места, чем традиционные .deb и .rpm пакеты, не проверяются командой дистрибутива (это магазин, куда кто угодно что угодно может загружать, были даже случаи троянов), медленно работают, потребляют довольно много RAM, захламляют вывод df и lsblk.

Из плюсов — работают на многих дистрибутивах, зачастую самый простой способ поставить последнюю версию ПО на старый LTS.

Да, и про Flatpak всё то же самое, кроме того, что я не слышал о троянах и нет захламления вывода df и lsblk.

Vsevolod-linuxoid ★★★★★
( 25.06.22 21:28:30 MSK )
Последнее исправление: Vsevolod-linuxoid 25.06.22 21:29:29 MSK (всего исправлений: 1)

Ответ на: комментарий от Vsevolod-linuxoid 25.06.22 21:28:30 MSK

плюсы флатпака перевешивают минусы все же, например, у меня хроминум из него и телега (лучше, чем в хомяк ставить из тарболов)

cetjs2 ★★★★★
( 25.06.22 21:47:49 MSK )
Ответ на: комментарий от cetjs2 25.06.22 21:47:49 MSK

Чем лучше? И кто мешает в /usr/local или в /opt поставить?

firkax ★★★★★
( 25.06.22 23:24:47 MSK )
Ответ на: комментарий от Heartbreak_Kid 25.06.22 14:03:45 MSK

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

einhander ★★★★★
( 25.06.22 23:49:48 MSK )
Ответ на: комментарий от firkax 25.06.22 23:24:47 MSK

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

cetjs2 ★★★★★
( 26.06.22 01:28:08 MSK )
Ответ на: комментарий от cetjs2 26.06.22 01:28:08 MSK

Это не тот пакетный менеджер, про которые говорят обычно.

firkax ★★★★★
( 26.06.22 01:51:18 MSK )
Ответ на: комментарий от Vsevolod-linuxoid 25.06.22 21:28:30 MSK

не проверяются командой дистрибутива

В отличие от флатхаба, на снапкрафте бОльшее количество официальных пакетов — те самые, с галочкой. Притвориться jetbrains или microsoft ты там не сможешь. Если же ты не доверяешь, скажем, фаерфоксу, собранному самой мозиллой — ну тут бог в помощь.

«Классические» снапы (без песочницы) публикуются только после ручного аудита: https://snapcraft.io/docs/reviewing-classic-confinement-snaps.

В остальных случаях предполагается, что песочница обережет, как и у флатпаков. Надо только помнить, что на flathub можно легко вместо манифеста для сборки забомбить готовый бинарь с уже вшитым чем угодно и filesystem=host

Я знаю про случай с майнером в клоне игры 2048. Какие еще случаи были?

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

Из остального: отсутствие дедупликации — да (что потенциально может вылиться в большее потребление RAM? не видел замеров с подтверждениями нигде). «Захламление» вывода команд маунтпоинтами — да, но обычному юзеру на это должно быть глубоко насрать (здесь надо бы упомянуть обязательный ~/snap — вот он уже может раздражать)

Из неупомянутых минусов: косяки с интеграцией (несовпадение тем, неработающие фичи из за песочницы итд); отсутствие контроля над обновлениями (как у винды десяточки и далее); отсутствие реальной кроссдистрибутивности (песочница не работает в других дистрибутивах)

Midael ★★★★★
( 26.06.22 02:50:30 MSK )
Последнее исправление: Midael 26.06.22 03:00:48 MSK (всего исправлений: 1)

Ответ на: комментарий от koshsky 25.06.22 13:52:59 MSK

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

висит в памяти всегда
100500 loop устройств
жрёт память и проц как игра ААА класса
пингует сервера постоянно
захлямляет систему сотней зависимостей
жрёт дисковое пространство как лось
если в нём что-то пойдёт не так ты бессилен что-то исправить

Спустя время научишься собирать софт и опакечивать.

Snap vs Deb.

Многие пользователи начинают интересоваться как технически устроена работа программы в snap пакете. По мере своих сил, как снапкрафтер, пытаюсь ответить на вопросы и вот решил вынести всё в одну статью. Буковок много, но для нетерпеливых в конце статьи есть краткая выжимка. Итак, мир deb против мира snap.

Установка программы

В традиционном мире deb пакетов ваша операционная система Linux (далее на примере Debian, Ubuntu. ) обладает списком источников софта, которые называются репозитории (repository). Вы можете поправить эти списки в файлах:

Официальные репозитории в файле /etc/apt/sources.list
Самостоятельно добавленные в каталоге /etc/apt/sources.list.d/

Устанавливая софт через GUI или CLI, ваш установщик-обновлятор софта вначале скачивает с репозиториев списки доступного в нём софта. Так как софт, как сложный программный продукт, сопровождающими (мантейнерами) традиционно разбивается на логические части, идущие в различных пакетах, то требуется обработать зависимости с помощью ресурсов вашего ПК и этот процесс называется full dependency resolution.

В мире snap источники софта называются хранилищами (store). Формально говоря, понятия зависимости в мире снап не существует. И один снап пакет с программой не зависит от другого снап пакета. Чуть ниже разжую один сложный момент, но в данном месте, чтобы вас не путать, условимся что в истинном понимании слова зависимость такого процесса как full dependency resolution в мире снап — НЕТ!

Установщик-обновлятор deb пакетов скачивает их с репозитория в каталог типа /var/cache/apt/archives/, распаковывает их содержимое по тем абсолютным путям, что идут в пакете деб. После ваших команд типа apt clean пакеты в /var/cache/apt/archives/ будут удалены, так как они выполнили свою задачу и больше не нужны.

Программа внутри snap сжата со всем необходимым ей с помощью squashfs. Пакет скачивается с хранилища в виде snap package в каталог /var/lib/snapd/snaps/ и НИКУДА и НИКОГДА не распаковывается. Пакет с программой банально монтируют в каталог /snap/ИМЯ-ПРОГРАММЫ/ВЕРСИЯ/

В мире deb специально программу дробят на различные пакеты, традиционно выделяя библиотеки/плагины/фреймворки в отдельные пакеты, чтобы делить их с другими программами. Рассмотрим упрощённый классический пример, когда программа А идёт в пакете a-v1.deb и зависит от пакета openssl-v1.deb и программа B из пакета b-v1.deb, зависящая так же от openssl-v1.deb. Говорят о том, что программа А и В де́лят между собой (share) общую библиотеку openssl-v1, а пакет a-v1.deb и b-v1.deb зависят от одного и того же пакета openssl-v1.deb.

В мире снап программу упаковывают вместе с тем, что ей необходимо ~~в загробной жизни~~ для работы. Возьмём вышеописанный пример и посмотрим как это будет выглядеть в мире снап. Внутри пакета a-v1.snap есть файлы программы А и openssl-v1 и внутри пакета В есть файлы программы В и openssl-v1.

Тут многие зададутся вопросом — зачем терять место на диске, таская в каждом снап пакете одно и тоже, отказываясь от классной штуки share?

Когда придумывали формат snap (он эволюционное развитие формата click), хотели прежде всего отказаться от full dependency resolution. Каждый из нас и не раз встречал ситуацию, когда разрешение зависимостей заканчивалось ошибкой. Вам нужно было пробовать столкнуть ситуацию с места командами sudo apt-get install -f или sudo dpkg —configure -a . Можно было попробовать переустановить пакет с установкой дефолтных настроек — sudo apt-get -o DPkg::options::=—force-confmiss —reinstall install ПАКЕТ_ПРОГРАММЫ Это всё попахивает не надёжностью в мире серверов и десктопа, а в мире мобильных устройств, для которых готовили формат snap, — это смерти подобно. Давайте пока дальнейший отказ Canonical от мобильной ветки и от идеи конвергенции тут не будем затрагивать, ибо snap пакет родом из мобильной сферы, но ею не ограничивается. Итак, фейл при установке пакета на телефоне. Как на маломощном устройстве сталкивать ситуацию с мёртвой точки при вероятной проблеме? Тем более full dependency resolution довольно таки затратная операция для ЦПУ. Нужна была надёжность в лице атомарности:
1) скачал snap пакет.
2) не затратно для CPU примонтировал пакет БЕЗ всяких full dependency resolution, ничего никуда не распаковывая.
3) получил новую версию программы.
4) если новая версия программа будет вызывать проблемы, то можно легко откатиться к старой версии, перемонтировав на старую версию пакета.

Занятое место

Давайте вопрос с занятым местом разрешим здесь навсегда.

Должен ли снап пакет, хранящий в себе всё что нужно программе + саму программу, быть жирнее аналогичного комплекса из деб пакетов этой же программы? Ответ — нет! Примеры в лице LibreOffice и Krita показали меньший размер в формате снап.

Будут ли множество программ в snap пакетах занимать больше места, чем они же в деб пакетах. Ответ — да. Без механизма share, когда масса программ могут использовать одни и те же компоненты, общий их размер будет больше.

Открою тайну, подлив масла в огонь хейтерам snap! Для поддержки механизма отката и возможности вернуться к старой работоспособной версии, в системе хранится несколько версий snap пакета программы.

Вот мой личный пример на момент написания статьи
ll /var/lib/snapd/snaps/

drwxr-xr-x 1 root root 334 авг 23 10:14 ./ drwxr-xr-x 1 root root 216 авг 25 13:18 ../ -rw-r--r-- 1 root root 83349504 июл 4 07:40 core_2312.snap -rw-r--r-- 1 root root 84393984 июл 17 15:21 core_2381.snap -rw-r--r-- 1 root root 84393984 июл 26 16:47 core_2462.snap -rw-r--r-- 1 root root 148656128 янв 5 2017 inkscape_1880.snap -rw-r--r-- 1 root root 149258240 фев 16 2017 inkscape_2527.snap -rw-r--r-- 1 root root 153026560 авг 10 07:47 inkscape_3080.snap -rw------- 1 root root 209604608 авг 8 08:58 languagetool_x1.snap -rw------- 1 root root 108244992 ноя 28 2016 pac-vs_x1.snap drwxr-xr-x 1 root root 0 ноя 24 2016 partial/ -rw-r--r-- 1 root root 85258240 июн 20 13:19 xnsketch_2.snap -rw-r--r-- 1 root root 154583040 июн 26 17:12 xnviewmp_1.snap

Мы видим 3 snap пакета core_*.snap, олицетворяющую операционную систему (об этом ниже). 3 пакета inkscape_*.snap программы Inkscape. Если вас напрягает такая ситуация, когда одна и та же библиотека находится внутри различных снап пакетов И снап пакетов одной и то же программы может быть несколько, то может сто́ит занятое место воспринимать как плату за ВЕРСИОННОСТЬ и НАДЁЖНОСТЬ?

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

Все программы внутри snap пакета изолированы от операционной системы и друг от друга профилем мандатного доступа AppArmor. Но и в темнице есть окна для связи со внешним миром. В терминах snap технологии — это интерфейсы (interface). Интерфейс — это когда plug соединён со slot. Хотите из программы звук? Просите при упаковке программы через snapcraft.yaml, чтобы plug pulseaudio соединили с одноимённым slot pulseaudio в системе (пакет ubuntu-core). До этого момента все slot предоставляла операционная система через снап пакет ubuntu-core. То есть ВСЕ программы, стыковались (connect) ТОЛЬКО со слотами системы и получали требуемое. Разработчики реализовали интерфейс content и стало возможно снап А соединить со снап Б.

Разработчики KDE активно щупали технологию Snap, чтобы попробовать представить своё детище в таком формате. Первые пробы упаковки KCalc рожали снап пакеты по 70 мб из-за kde-frameworks-5 внутри, но стоило воспользоваться интерфейсом connect и вынести kde-frameworks-5 в отдельный snap пакет, то KCalc похудел до 300 кб

Художник во мне от слова худо, поэтому попытался вам нарисовать ситуацию ДО и ПОСЛЕ появления content interface.

К сожалению, до сих пор графическая Ubuntu Software не умеет разруливать такие ситуации, когда вы ставите пакет снап А, а он будет просить коннекты к пакету Б. Я видел даже графические наброски разрабов, но пока такое не реализовано и, на примере KCalc вы можете пока только в консоли скомандовать
sudo snap install kcalc
sudo snap install kde-frameworks-5
sudo snap connect kcalc:kde-frameworks-5-plug kde-frameworks-5:kde-frameworks-5-slot

При установленных пакетах можно исследовать как именно реализуется механизм — два пакета организовывают коннект к друг другу?

Снапкрафтер из проекта КДЕ при упаковке kcalc создавал snapcraft.yaml, который внутри пакета будет лежать у вас в системе по адресу /snap/kcalc/current/meta/snap.yaml

Нужная для понимания часть файла.

apps: plugs: - kde-frameworks-5-plug - home - x11 - opengl - network - network-bind - unity7 - pulseaudio plugs: kde-frameworks-5-plug: content: kde-frameworks-5-all default-provider: kde-frameworks-5 interface: content target: kf5

Что мы видим? Plugs с именами home, x11, opengl, network, network-bind, unity7, pulseaudio будут соединены с одноимёнными slots к ubuntu-core, которая олицетворяет систему. kde-frameworks-5-plug использует интерфейс content.

Теперь анализируем /snap/kde-frameworks-5/current/meta/snap.yaml

slots: kde-frameworks-5-slot: content: kde-frameworks-5-all interface: content

Мы видим слот kde-frameworks-5-slot, использующий интерфейс content.

Кто-то скажет, что ушли от понятия зависимости в мире deb, но connect между snap пакетами чем не связь-зависимость? Частично вы правы, но дьявол прячется в мелочах. Сейчас в большинстве дистрибутивов linux вы не можете иметь несколько одновременно установленных в системе библиотек типа gtk/qt или различных версий runtime типа KDE Frameworks. Новые версии библиотек и runtime вынуждают сторонних авторов ПО отслеживать их API/ABI и частенько переписывать свои детища, если они хотят и впредь видеть свою программу в официальных репозиториях. Более подробно лучше прочесть в статье Разработчики GTK хотят разрушить Linux desktop. В мире snap можно в операционной системе обладать несколькими версиями библиотек/runtime и просить коннект к нужной. Это тонкая грань между зависимостями (dependancy) в мире deb и соединениями (connect) в мире snap, но её нужно понять на уровне ДНК.

Работа программы

В данном разделе давайте рассмотрим различия в работе программ, установленных из деб и снап пакетов. Большинство Linux систем — это discretionary access control (DAC). Вы установили программу А и при запуске её бинарника, в памяти он становится понятием — процесс. Запускали программу вы от своего имени и процесс будет обладать теми правами, которыми обладает ваша учётная запись. Если вы можете зайти в папку /share/folder_x/ и прочесть файл secret.txt, то и программа А сможет это сделать. В традиционном мире Linux мы надеемся на порядочность программистов, пишущих софт, и на внимательность сопровождающих пакета, которые пытаются не допустить злоупотреблений. Молимся, чтобы сетевой программой удалённо не кукловодил злоумышленник, отправляя к себе наши файлы, поимев программу через дыры. То есть в мире DAC нам остаётся надеяться, верить и молиться.

Мир snap — это mandatory access control (MAC). Снапкрафтер при упаковке программы в декларативном виде описывал многие вещи в файле snapcraft.yaml, в том числе к каким интерфейсам он желал бы подключить программу. Эти желания будут развёрнуты в правила системы мандатного доступа AppArmor и проанализировать их можно по адресу /var/lib/snapd/apparmor/profiles/

Следует помнить, что мир MAC строже чем DAC. Программа находится в изоляции и может только то что ей разрешено профилем. В мире снап запущенная программа А не сможет зайти в /share/folder_x/ и прочесть файл secret.txt при всём её желании. Отсюда следует вывод, который многие упускают. После установки программы в виде снап пакета, любой её бинарник НЕ сможет что-либо считать, кроме как из пути /snap/ИМЯ-ПАКЕТА/ВЕРСИЯ/

Другими словами и ещё раз. НЕЛЬЗЯ считать и подгрузить из вашей системы бинарники, библиотеки из /usr/, /lib/ . Интерфейс home, если он запрошен, даёт ограниченный и фильтированный доступ к вашей домашней папке ~/.

Зачем и кому нужен snap?

Сторонний программист со своим прикладным софтом

Snap задумывался как упрощение процесса попадания прикладного софта от стороннего программиста в официальные репозитория-хранилища. Из-за того, что в деб пакете есть скрипты post/pre inst/rm, выполняющиеся от root, сопровождающему при любом обновлении софта снова требуется визировать новую версию. Более подробно Контр доводы к словам Кайла Кина.

В мире снап, если вы не будете заявлять об исключениях в безопасности, то рассмотрение снап пакета будет проходить в автоматическом режиме и будет одобряться автоматом после прохождения вереницы тестов. Всё это возможно, благодаря использованию обязательного профиля AppArmor и правил seccomp.

Пользователь

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

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

Системный администратор

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

Кратко

Давайте кратко всё резюмирую.

Deb	Snap
Программу с её библиотеками в мире деб красиво представляют в виде множества пакетов, которые зависят друг от друга.	В снап пакете обычно идёт программа со всем необходимым ей. Иногда тяжёлые фреймворки выносят в отдельный snap и делают к нему connect.
Deb пакеты скачивают, распаковывают содержимое, выполняя рихтовочные control скрипты.	Snap пакет скачивают и монтируют в каталог, ничего никуда не распаковывается. Внутри сжатого пакета снап нет каких-либо скриптов, которые вызываются кем бы то нибыло.
Программа из пакета deb ничем не ограничена и получает доступ ко всему к чему у вас есть права.	Программа в snap пакете работает в изоляции. Получает нужное через интерфейсы и не получает какой-либо доступ, даже если у вас есть на это права.
В мире deb сложнее осуществляется версионность. Откат к старой версии может быть технически невозможен, ибо в репозитории может отсутствовать старый пакет к этому времени. Процедура понижения версии (downgrade) непроста и редко используется в практике. Атомарность не гарантируется. Все стараются, чтобы при обновлении всё прошло гладко, но не всегда система может быть переведена из одного рабочего состояния А в другое Б.	Snap пакеты поддерживают атомарность и версионность. Вы можете откатывать софт к версии ранее и пакет или ставится полностью или не ставится совсем, если есть какие-то технические проблемы.

Дата последней правки: 2017-08-26 15:46:41