Комментарии 31
apt purge snapd это чуть ли не первое, что я делаю после установки ubuntu-based дистра.
Пока единственные проблема - размер пакетов, в том числе и хвосты давно обновлённых. И при установке пару раз была ошибка, которую сложно разобрать ибо магазин о пакетах говорит в маленьком блочке текста. Больше ни с чем эдаким не сталкивался.
PS у меня и до этого момента были некоторые проблемы со снапом, но там всё было осознано и при упирании в такие же проблемы снап уходил на покой… Кстати уже после всего этого я прочитал, что даже в описании при установке написано — это снап пакет, но кто читает это описание то а?
Удивлен. Я думал snap нужен для создания самодостаточных пакетов, а не изоляции.
Спасибо, в следующий раз буду думать прежде чем ставить через него ПО.
И спасибо что напомнили про интеграцию с ssh агентом. Тоже давно пользуюсь keepasscx.
Бывало всякое, но не со snap, а с пакетами в AUR (Manjar).
Zoom в течение нескольких месяцев после каждого обновления то нормально воспринимал системный DPI (у меня 2к монитор), то использовал вшитое в пакет значение. С ним приложение растягивалось на весь экран (причем в процессе возникало сильное размытие интерфейса), кнопки становились в несколько раз больше обычного, но текст на них наоборот становился меньше.
Telegram и Discord из-за вшитой в них функции автоматического обновления пытаются скачать и установить пакет самостоятельно, но либо падают из-за нехватки прав на запись в системную директорию, либо в процессе перезапуска не могут найти исполняемый файл по стандартному пути и просто завершаются, из-за чего их приходится запускать руками.
Intellij Idea и основанные на нем продукты (DataGrip, PyCharm) устанавливались в виде двух пакетов, например datagrip и datagrip-jre. Второй был нужен для поставки нужной версии Java, отдельно от системной. Однако оба пакета весили по 2.5Гб, что при установке нескольких продуктов от Intellij быстро съедало место в системном разделе. Как оказалось, JRE зачем-то присутствовал сразу в обоих пакетах, но второй удалить было нельзя, т.к. он был обязательной зависимостью первого.
KeeWeb (аналог KeePassXC, но на Electron), установленный из пакета keeweb, после обновления перестал отвечать на запросы авторизации от браузерного расширения.
Как оказалось, пакет собирается на основе .deb пакета, но вместо полной перепаковки из него только извлекаются некоторые бинарники, а само Electron приложение собирается локально. Но в новой версии работа с расширением была тоже вынесена в один из бинарников, а скрипт перепаковки его не учитывал.
И кроме того, что бинарника не было в системе, само по себе приложение оказалось не готово к новому способу сборки.
Суть в том, что в .deb пакете keeweb был исполняемым файлом (electron + зашитое в нем название приложения и пути). А при пересборке использовался системный Electron, который вместо бинарника создавал архив с ресурсами приложения (в формате .asar), а файл keeweb представлял из себя скрипт:
electron /usr/lib/keeweb/app.asarПриложение получало путь к исполняемому файлу через app.getPath('exe'), а по нему получало путь к лежащему рядом бинарнику, необходимому для интеграции с браузером. Но системный electron возвращает при вызов этой функции не путь к архиву (/usr/lib/keeweb/app.asar), а путь к собственному исполняемому файлу (/usr/lib/electron/electron), где нужного файла уж точно быть никак не могло.
Проблема решилась после переезда на пакет keeweb-desktop-bin, который просто перепаковывал исходный .deb без дополнительных шагов по локальном сборке всего приложения.
Но и со snap пакетами были различные истории. У одного из сотрудников после ухода ноутбука в сон пропадал доступ к запущенному в докере приложению, запрос к http://localhost:3000 падал с ошибкой Network unavailable. Как оказалось, на интерфейсе docker0 пропадал IPv4 адрес, оставался только IPv6, но в /etc/docker/daemon.json IPv6 был выключен. В результате сети хоста и докера оказались полностью изолированы друг от друга. Попытка перезапуска docker ни к чему не привела, т.к. в snap пакете были ещё и неправильные systemd службы - вместо docker.service была своя snap.docker.docker.service с отличными от оригинальной путями и зависимостями. Пришлось сносить и ставить официальный пакет.
Ссылки из скайп, установленного через snap, открывались в "песочном" Firefox, т.е. абсолютно чистом, без плагинов, вкладок, регистраций на сайтах. Снёс, поставил через deb пакет.
Snap, на самом деле, достаточно прогрессивная штука.
Приложения устанавливаются в песочнице, цикл доставки кода подходит намного быстрее чем через "традиционые" репозитории.
Но с точки зрения "уверенного пользователя" это выглядит не так радужно, к сожалению.
Кстати, snap удален из mint последних ревизий.
например, telegram из flatpak, и telegram, тот что tar.xz архив из офф. сайта — вообще не одно и то же.
тот что из flatpak, не запоминал размер окна после закрытия, отлипал от краев тоже например. даже внутри программы не было некоторых настроек.
наверно опаздывает на пару версий, хотя какая разница, неохота и смотреть.
Да, сталкивался с проблемой с remmina из снапа. Пропадает список сохраненных подключений после обновления. И после нескольких перезагрузок восстанавливается. После этого удалил снап из системы и поставил ремину из репозитория.
Особенности:
1. У приложений нет доступа к некоторым частям ФС и это нельзя настроить. Если пользователь по какой-то причине хранит файлы за пределами домашней директории, то доступ к ним из изолированного снап пакета не разрешить даже вручную.
2. Если снап пакет «classic» и с полным доступом к ФС, то тут тоже есть нюанс. Такие пакеты не могут нормально взаимодействовать с pulseaudio и будут стучаться в alsa на прямую. Что может вызвать проблемы со звуком как в рамках приложения, так и в рамках системы в целом. Примеры: skype, slack.
3. Страдает интеграция между приложениями, типа автоматической вставки из кипаса или поддержки расширенных систем ввода fcitx.
Установка из snap с флагом --classic не помогает? Или вы через гуй устанавливали?
Добавить / извлечь вложения из thunderbird установленного через snap часто (не всегда) становится квестом :)
У меня со snap была и есть следующая проблема - это при установке vlc. Если запускать видеофайл с системного диска, то все норм. Но если видеофайл находится на другом примонтированном диске (оба диска зашифрованы и доступны для чтения\записи), то ничего не работает - ошибка кодеков. При копировании на системный диск, проблема уходит. При установке vlc из пакетов, такой проблемы нет.
Вот оно что. То же самое было на днях. Спасибо за подсказку.
Из snap использую только certbot, потому как apt'овская версия значительно устарела и не поддерживает EC-сертификаты.
Осторожно, snap