Комментарии 60
Что думаете про Haiku-шные hpkg? Выглядят продуманно.
На хабре даже есть перевод цикла обзоров HaikuOS от создателя AppImage) Вот самая релевантная статья https://habr.com/ru/company/southbridge/blog/466301/
в snap есть еще такая проблема, например с vlc, установил, а при попытки запустить видео с другого примонтированного (с luks шифрованием) диска ошибка.
Помнится даже microsoft анонсировала запуск всех приложений в песочнице и использованием контейнеризации, но что то сейчас тишина. Поэтому думаю, что вскоре появятся новые рантаймы и запуск приложений будет идти в эту сторону.
Сжатие образов в snap — это не только минус (время на распаковку), но и плюс.
Например, с продуктами JetBrains пользоваться snap очень удобно, а каких-либо проблем с производительностью я не заметил. Зато сразу бросается в глаза экономия места (от полгига до гига на одну IDE вместо несколько гигов + многих тысяч файлов) и супербыстрая установка/обновление.
Зато сразу бросается в глаза экономия места
Это когда любая утилита тянет за собо 200мб runtime-а. Если пак один то да, а если сотни то ситуация обратная.
Зато сразу бросается в глаза экономия места
Я понимаю, почему бизнесам в области хранения данных есть дело до места. Но вам-то, как конечному пользователю, какая разница? Диски меньше чем на полтерабайта сегодня большая редкость. Ну съест ваш пакет гигабайт-другой, ну десять, на что это повлияет? Стоимость хранения данных продолжает падать, в то время как вычислительные мощности практически не растут последнее десятилетие (если не считать прогресса в области SIMD систем, но это таки другое), так что размен производительности на экономию места в общем случае выглядит неразумным.
Экономия места - она за счёт сжатия. Отсюда быстрая установка и обновление, но медленный старт и работа. И по-моему основное - это как раз работа.
Мы берём современные nvme не для того, чтобы экономить место, а чтобы софт максимально быстро работал с файлами. И с этой точки зрения сжатие - не самая умная идея: оно тормозит работу с ФС, и дополнительно нагружает процессор.
На HDD сжатие имело смысл - там шины были узкие, процессор простаивал, выгоднее было нагрузить процессор и разгрузить шины. Но на nvme, ИМХО, доступ к тысячам файлов, он быстрее будет напрямую.
От тысяч файлов никуда не уйти - IDE так или иначе с ними работает. Просто в одном случае она один раз чуть дольше устанавливается, зато быстро может обращаться к файлам в любой момент, а в другом случае она чуть быстрее устанавливается, зато дополнительно тормозит и при запуске и при обращении к файлам, потому что вынуждена продираться через дополнительные слои распаковки.
К тому же нативно для IDE ещё и работает родной toolbox, через который проходит синхронизация, обновления, управление интеграцией в систему, очистка временных файлов, и там же небольшой аналог машины времени встроен: если новая версия не зашла, можно за секунду откатиться к предыдущей, гарантировано рабочей версии IDE. Не думаю что все это будет корректно работать со snap.
Ну да, копирование с NVMe накопителя происходит немного быстрее, чем из snap-образа:
# sync; echo 3 > /proc/sys/vm/drop_caches
/var/lib/snapd/snap/rider$ time cp -r current/ /tmp/1
real 0m2,586s
user 0m0,013s
sys 0m2,137s
# sync; echo 3 > /proc/sys/vm/drop_caches
/home/andrew/tmp/rider$ time cp -r current/ /tmp/1
real 0m1,881s
user 0m0,003s
sys 0m1,041sЦелых 2.5 секунды в SNAP против 1.8 секунд напрямую для 3 гигабайт данных.
Эта разница настолько микроскопическая, что увидеть её в реальности невозможно.
Более того, я не замечаю разницы даже между SATA II SSD и NVMe, потому что мало уметь читать данные с бешеной скоростью, надо их уметь с такой скоростью обрабатывать. Если бы загрузка IDE заключалась в простом копировании файлов в память, то она бы стартовала за полсекунды.
Мы берём современные nvme не для того, чтобы экономить место
Ну да, то же самое можно и про оперативную память сказать. JetBrain ToolBox съел полгига памяти — да не жалко, у нас же их целых 64 гига.
Так что если есть возможность сэкономить 10 гигов просто за счёт эффективного сжатия, не вижу проблем. Есть возможность отказаться от прожорливого ToolBox — тоже хорошо.
P.S. Лично я NVMe брал, в первую очередь, ради экономии места, причём физического. Маленькая плашка занимает сильно меньше места в корпусе компьютера, чем диск формата 2.5 или вообще 3.5.
@myxoсистема установки приложений в MacOS ведь тоже работает с примонтированными образами, как и snap. Знаете ли вы плюсы и минусы их подхода, и пробовал ли кто-то использовать их наработки в линукс?
Почему холодный старт долгий?
Линукс умеет разделять в памяти код общих библиотек между приложениями, загружая их с диска в память только один раз при помощи mmap. Когда условный Firefox установлен deb пакетом, то к моменту запуска приложения большая часть околосистемных зависимостей уже находятся в памяти и фактически подгружается лишь небольшой кусок.
Snap хоть и обещали дедупликацию с самого начала, но афаик ни чего не сделали до сих пор. Поэтому каждое приложение при запуске читает с диска в память все зависимости, что создаёт огромный оверхед.
В прошлом году Canonical изобразили жест отчаяния, сделав в Ubuntu установку FF из Snap безальтернативной (а может это заговор?). На что мозилле пришлось спешно рассказывать пользователям как устанавливать браузер с помощью deb из PPA. В январе была статья, что Canonical собираются в очередной раз все сломать починить https://ubuntu.com/blog/the-future-of-snapcraft. Но результатов я ещё не видел.
У flatpack в этом плане все гораздо лучше, поскольку они распаковывают приложение на файловой системе, что позволяет задействовать имеющиеся механизмы для дедупликации.
Дедупликация работает только если libfoobar.so.1.0 загружается множеством приложений. Если же каждое привозит свою копию - дедупликации не будет.
flatpack предлагает т.н рантаймы которые будут переиспользовать библиотеки, но только если используется одинаковая версия рантайма.
К сожалению все эти системы все равно повязаны на способность взаимодействовать с конкретными системными библиотеками, и что делать тем приложениям которые например повязаны на старые версии видеодров пока не ясно.
На что мозилле пришлось спешно рассказывать пользователям как устанавливать браузер с помощью deb из PPA.Мозилла ничего против snap-пакета не имеет. Более того, этот snap-пакет именно Мозилла и собирает.
«Спешно рассказывает» некий Joey Sneddon из сетевого издания OMG! Ubuntu!
максимально точное обьяснение, почему никаких снапов и аппимеджей не будет на моём персональном компьютере по возможности никогда.
флатпак такое же зло что и первые два. И вообще экономить на (однократном) создании системы нормальных билдов под пяток популярных архитектур и дистров за счёт многапользователей впоследствии - плохая идея.
Согласен с вами! На мой взгляд, уж лучше тогда возвращаться к полностью статическим бинарникам, как было во времена MS-DOS. Вообще, эти .so и .dll изначально придумали для экономии памяти. Но сейчас это не столь актуально (а если набор .so у каждого приложения свой, без дедубликации, то наоборот, и памяти расходуется больше, и время запуска приложения растёт).
то к моменту запуска приложения большая часть околосистемных
зависимостей уже находятся в памяти и фактически подгружается лишь
небольшой кусок.
А это измеряли? Просто glibc и gtk это 3-4 мегабайта, а вот какой-нибудь libxul.so это сотня мегабайт. За счет использования общих библиотек вся система должна быстрее работать, но каждое "большое" приложение (типа браузера, офисного пакте и т.п.) должно все лишь чуть чуть ускоряться, так как там неразделяемого кода до фига и больше.
Из этих трёх я предпочёл бы AppImage за его простоту. Snap и Flatpak какие-то overengineered вундервафли, излишне всё усложняющие. А sandboxing должен быть реализован отдельным инструментом, без привязки к пакетному менеджеру.
А вообще старые добрые тарбол-бандлы и так были ок. Вон как Mozilla свои продукты распространяет много лет со своего сайта. Ну подумаешь место на диске неэффективно используется, я предпочту пожертвовать этим.
Кстати, идея не нова, много лет уже был проект Zero Install https://0install.net/ и по мне так реализация получше Snap и Flatpak. Но за ним не стоит корпорация, поэтому без агрессивного навязывания известен только в узких кругах.
Ну и ещё по своему проблему решают в дистрах Nix, Gobolinux (не в курсе жив ли ещё) и прочих.
Жизнь всем этим начинаниям сильно портит то, что во многих дистрибутивах часть библиотек идут со специфичными модификациями. Поэтому даже при номинальном совпадении версий, GUI приложений, собранных в разных условиях, визуально может заметно отличаться - начиная с банального рендеринга шрифтов, нюансов тем, поддержки кодеков и т.п. AppImage это не решает ни как. tgz либо так же (при статической линковке), либо уповают на проведение что все звёзды сойдутся и приложение вообще запустится (при динамической). Flatpack собирают приложения в контролируемой среде, что обеспечивает консистентность между ними хотя бы внутри экосистемы.
Nix кстати на ubuntu пользуюсь, там бывают пакеты, которые сложно найти в других местах.
Вот нужно мне приложение Х для Linux, оно распространяется разработчиком в виде нескольких разных таких упакованных вариантов — какой мне лучше выбирать и от чего это зависит?
Многообразие дистрибутивов и следовательно форматов пакетов. Для поддержки всех версий нужно прилагать огромное количество усилий. Посмотрите только на такие плашки, сам факт того, что они существуют, несколько пугает.
достаточно использовать сборщик который умеет сам из одной инструкции собирать пакеты для 100500 версий дистрибутивов и пм.
А что делать, если двум приложениям требуются разные, несовместимые версии пакетов?
бить разработчиков использующих версии либ который появились "вот только вчера)
А что делать если приложению нужен пакет, который не предоставляется дистрибутивом?
а как простите пакет с неудовлетворённой зависимостью попал в репы? в вашем дистрибутиве мейнтейнеры предпочитают мефедрон?
А что делать авторам приложений, если они хотят выкатить новую фичу, но она опирается на версию другого пакета, которого ещё нет в каких-то дистрибутивах. Скорость инноваций сильно падает и в некоторых областях это очень критично.
всё просто, покласть нужную версию нужной либы в отдельное репо с отдельным именем. уживались же не один год python2 и python3 вместе в куче разных дистрибутивов (и да есть ещё куча примеров).
Если дистрибутив обновляется (а вместе с ним все пакеты), нужно проверять работоспособность приложения. При этом хочется верить, что ментейнеры у проекта ещё есть. И да, вам будут присылать баг репорты на старые версии приложения в старых дистрибутивах, то есть нужно ещё поддерживать старые версии продукта, нельзя просто сказать "это починено в новой версии, обновитесь"
чтобы работало нужно работать. это претензия?
Возможность поправить баг и обновить пакет для всех - обоюдоострый меч. По причине того, что это иногда банально сложно - исправить что-то и сохранить все контракты (явные и неявные) вашей библиотеки. Вполне возможно своим "фиксом" автор пакета неявно создаст баг всем другим, кто от него зависит.
см предыдущий пункт
вообще я не понимаю этого - чтобы избавиться от зоопарка проблем породили новый зоопарк с ещё большим количеством проблем.
мегать несколько способов поставки ПО в одной системе это выстрел себе в ногу. хотите мешать в одном дистре пакеты из реп и снапофлатпаки будьте готовы к геморрою.
ps: По поводу снапов им подобным, есть же статическая линковка, что мешает? И на крайняк есть LD_LIBRARY_PATH, и --rpath=$ORIGIN/libs
ps: По поводу снапов им подобным, есть же статическая линковка, что мешает? И на крайняк есть LD_LIBRARY_PATH, и --rpath=$ORIGIN/libs
статическая линковка тоже костыль, причём костыль влияющий как на вес бинаря так и на скорость холодного старта (в случае go и rust не так сильно конечно, но ведь не весь софт на них написан).
Проблема в динамических библиотеках
В самих динамических библиотеках нет проблемы, проблема, как обычно бывает, в абсолютизации концепции. У всякого подхода есть границы применимости, но адепты "построим ВСЮ систему на централизованных репозиториях и разделяемых библиотеках" почему-то считаются светочами мысли.
Аналогия: Представьте пришли вы в библиотеку взять несколько книг, а вам говорят надо брать весь фонд иначе никак. Даже выписать пару страниц из книги нельзя, только целиком библиотеку берите. А некоторые книги еще и в разных библиотеках.
хотите мешать в одном дистре пакеты из реп и снапофлатпаки будьте готовы к геморрою.
Нет никакого геморроя, потому что традиционные репы + FHS никак не пересекаются с Flatpak. И практика тоже это показывает.
А что делать, если двум приложениям требуются разные, несовместимые версии пакетов?
Объясните, пожалуйста, тупому, а почему зависимости нельзя просто версионировать? Допустим, приложению Калькулятор нужна библиотека libabc версии 0.25, а для приложения Календарь libabc версии 0.31. Ну и бога ради, пусть они обе одновременно присутствуют в соответствующих подкаталогах. Пакетный менеджер при установке пакета пишет в какой-нибудь реестр, какая приложенька зависит от какой версии, а ядро при линковке обращается к этому реестру и выбирает нужную версию. При удалении пакета можно пройтись по реестру и вычислить, нужна ли зависимость какому-то другому пакету, и если не нужна, то она удаляется. То же самое при обновлении - в реестр записали новые зависимости и удалили старые, если они больше никому не нужны. Для замособранных программ, которых нет в реестре, по дефолту вибирается самая свежая версия библиотеки.
Как по мне и реестр не нужен. Кидать эти библиотеки в те же папки, но указывать версии с разными подробностями: lib.so.1.2.3, lib.so.2.1.3, lib.so.2.2.4, lib.so.1 -> lib.1.2.3, lib.so.2 -> lib.2.2.4. lib.so.1.2 -> lib.so.1.2.3, lib.so.2.2 -> lib.so.2.2.4.
Менеджеру пакетов только устанавливать ссылки на библиотеки без указания минорной версии и патча.
Почему так не делается непонятно. Наверняка есть какая-то весомая причина.
Получается, остались организационные вопросы?
Не ломать обратную совместимость в пределах мажорной версии.
В приложениях указывать необходимый минимум по версии библиотеки.
Не верю, что проблема только в этом. Потому что задача становится решаемой.
Насколько я понимаю сигнатуры функций можно проверять автоматически, т.е. отлавливать нарушение обратной совместимости.
Ссылки на жёстко зафиксированные версии мы тоже можем отлавливать автоматически.
В обоих случаях есть 2 решения:
Рекомендовать разработчикам не ломать обратную совместимость в рамках мажорной версии или повысить мажорную версию.
Внутри дистрибутива вести своё сквозное версионирование библиотек.
Да, оба варианта сопряжены с некоторыми сложностями, но разве эти сложности сопоставимы со сложностью приложений описанных в статье?
AppImage хорош для игр и всякого специфического софта, которому не нужно плотное сопровождение со стороны мантейнеров.
Flatpak — ну, норм. Вижу его репозитории много всякого софта, которого нет в дистрибутивных репах и даже AUR, так что его полезность положительна. Однако есть пара проблем: каталог со служебными файлами софтины (настройки, кэши, базы) лежит не в хомяке, а где-то в дебрях иерархии flatpak, плюс ещё бывает, запустишь программу из флатпака, а она вместо нормальной отрисовки шрифтов — пилой по глазам.
Snap возненавидел за первые несколько минут использования за его тормоза и загаживание mount. Ужасное поделие. Надеюсь, умрёт в пользу Flatpak.
Ещё один момент - приложение монтируется в read only файловую систему.
Это значит, что приложение не может обновлять само себя, нужны внешние утилиты.
Не совсем так. Для AppImage есть https://github.com/AppImage/AppImageUpdate, который можно использовать как библиотеку для self-update.
Я имел в виду, что некоторые приложения (например тот же телеграмм) умеют самостоятельно выкачивать свои обновления и заменять свой бинарник. С AppImage же нужна именно внешняя тула, которая будет обновлять .appimage файл.
Ну или учить приложение, что оно может быть AppImage'ом и передавать ему путь к .appimage файлу, но это такое себе…
Ага, ясно. Самое главное в статье:
Распространение приложений в линуксе - это боль. Причем в наше время цикл обновлений приложений все уменьшается и эта боль чувствуется все сильнее.
Оно так и есть ? У меня есть знакомый, который под винду накалякал утилиту ещё в эпоху ХР. Почти сразу он на неё забил, но утилита свои задачи выполняет до сих пор. И пусть она не мегапопулярна, но десятки тысяч людей все эти годы благодаря ей получали решение своей проблемы. На винде. Что было бы, вздумай он сделать такую же утилиту для Linux и забить? Уже через пару-тройку лет она перестала бы собираться и/или запускаться.
Ну и зачем производелям софта нужен такой головняк? Даже крупные конторы с сомнением смотрят на эту шизофреническую спецолимпиаду под названием "удержи своё Linux-ПО на плаву", а мелким конторам и отдельным энтузиастам это и подавно не нужно.
Полностью с вами согласен. В студенческие времена тоже много утилит на Дельфи писал, и они работают до сих пор. А вот под линукс надо раскорячиваться очень сильно. Благо, есть Rust, который можно собрать под musl, чтобы хотя бы не зависеть от кучи разных версий glibc.
Религия линукса :) В статье же написано, что выбран другой путь - экономия на спичках места, которое занимают либы.
Так это ж не то. Тут проблема в том, что из статической линковки с glibc ничего дельного не выйдет. Поэтому кто-то вместо него использует musl.
С другой стороны, собранный на древней версии glibc софт с большой долей вероятности успешно запустится на более свежих дистрибутивах. Собственно, мы так и делаем: сборка идёт под Ubuntu 16.04, все зависимости тянем с собой, предварительно пропатчив у них rpath. И никаких контейнеров, переменных окружения и конфликтов зависимостей.
Что было бы, вздумай он сделать такую же утилиту для Linux и забить?
У меня на сравнительно свежей федоре стоит и работает бинарный пакет Альтлинукса 2005 года сборки 2010 года установки. И ещё что-то с Мандривы 2011 года.
snap плохо работает, когда надо работать с данным на nfs shares, и всё совсем фигово, когда /home тоже на nfs.
Что господа думают об https://spack.io/?
Блин, проголосовал неправильно. Выбрал "Репозиторий моего любимого дистрибутива", тогда как надо было ткнуть и в snap (да, у меня Ubuntu и, нет, я не выпиливал из неё ВЕСЬ snap), и в AppImage.
AppImage удобен когда хочешь просто посмотреть на приложение, но не заморачиваться с добавлением PPA и установкой всех его зависимостей. Например Cool-Retro-Term. Забавная софтинка, но собирать её руками и потом поддерживать? Проще скачать один файл.
snap-ы выглядят как-то странно, но тем не менее, joplin и microk8s (ну и ещё всякое) я ставил из них.
Из тех же соображений, что и AppImage, но с возможностью автоматического обновления.
В целом, если всё это не навязывается (привет FF в Ubuntu), использовать можно, иногда даже удобно.
Как работают snap, flatpak, appimage