Что такое appimage в linux. запуск и установка

Достоинства

Плюсы такого решения очевидны. Как было сказано выше, нет проблем с установкой зависимостей. Все работает «из коробки».

Вы получаете программу именно с теми компонентами, с которыми автор данной программы (или тот, кто формировал AppImage) ее тестировал и гарантирует ее работу.

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

AppImage можно запускать и в Live-системах или с флешки.

Чтобы удалить AppImage достаточно удалить AppImage-файл.

B. How to use AppImage in Linux

Using AppImage is fairly simple. It is done in these 3 simple steps:

• Download AppImage file
• Make it executable
• Run it

Don’t worry, I’ll show you how to run AppImage in details. I am using Ubuntu 16.04 in this AppImage tutorial but you can use the same steps on other Linux distributions as well. After all, the entire point of AppImage is to be independent of the distributions.

Step 1: Download .appimage package

There are plenty of software that are available in AppImage format. GIMP, Krita, Scribus and OpenShot are just a few names. You can find an extensive list of applications available in AppImage format here.

I will be using OpenShot video editor in this tutorial. You can download it from its website.

Step 2: Make it executable

By default, the downloaded AppImage file won’t have the execution permission. You’ll have to change the permission on the file to make it executable. You don’t need root privilege to do that.

If you prefer the graphical way, just right click on the downloaded .appimage file and select Properties.

Right click on AppImage file and select Properties

In the next screen, go to the Permissions tab and check the box that says “Allow executing file as program”.

Make the AppImage file executable

That’s it. You have made the file executable.

Alternatively, if you prefer the command line, you can simply use chmod u+x <AppImage File> to make it executable.

Step 3: Run the AppImage file

Once you have made the AppImage file executable, just double click on it to run it. It will see the software running as you would have installed it on your system. Cool, isn’t it?

Creating AppImages

The general workflow for creating an AppImage involves the following steps:

1. Gather suitable binaries. If the application has already been compiled, you can use existing binaries (for example, contained in .tar.gz, deb, or rpm archives). Note that the binaries must not be compiled on newer distributions than the ones you are targeting. In other words, if you are targeting Ubuntu 9.10, you should not use binaries compiled on Ubuntu 10.04. For upstream projects, it might be advantageous to compile special builds for use in AppImages, although this is not required.
2. Gather suitable binaries of all dependencies that are not part of the base operating systems you are targeting. For example, if you are targeting Ubuntu, Fedora, and openSUSE, then you need to gather all libraries and other dependencies that your app requires to run that are not part of Ubuntu, Fedora, and openSUSE.
3. Create a working AppDir from your binaries. A working AppImage runs your app when you execute its AppRun file.
4. Turn your AppDir into an AppImage. This compresses the contents of your AppDir into a single, self-mounting and self-executable file.
5. Test your AppImage on all base operating systems you are targeting. This is an important step which you should not skip. Subtle differences in distributions make this a must. While it is possible in most cases to create AppImages that run on various distributions, this does not come automatically, but requires careful hand-tuning.

While it would theoretically be possible to do all these steps by hand, AppImageKit contains tools that greatly simplify the tasks.

See the Wiki for details and for examples on how to bundle real-world software such as LibreOffice, Google Chrome, and others as AppImages.

Предыстория

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

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

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

Description

Objectives

AppImage aims to be an application deployment system for Linux with the following objectives: simplicity, binary compatibility, distro agnosticism, no installation, no root permission, being portable, and keeping the underlying operating system untouched.

Properties

AppImage does not install the application in the traditional Linux sense. Instead of putting the application’s various files in the distro’s appropriate places in the file system, the AppImage file is just the application’s compressed image. When it runs, the file is mounted with FUSE. This behavior is consistent with AppImage’s predecessors, klik and PortableLinuxApps.

It uses one file per application. Each file is self-contained: it includes all libraries the application depends on that are not already part of the targeted base-system. An AppImage of version 1.0 is an ISO 9660 Rock Ridge file (which can be optionally zisofs compressed) containing a minimal AppDir and a tiny runtime. (Version 2 may use other file system image formats like SquashFS). An AppImage application can be added to a live CD by adding only one file to the live CD.

AppImage files are simpler than installing an application. No extraction tools are needed, nor is it necessary to modify the operating system or user environment. Regular users on the common Linux distributions can download it, make it executable, and run it.

AppImage allows generation of embedded digital signature, which need to be verified with an external utility. The format does not offer form of self-check with package authenticity verification or runtime confinement by sandboxing.

The “Hello World” example

In this section, we’ll learn how to build a basic AppImage with the classic “Hello World” example. So, for this example, our “app” is simply a shell script that prints “Hello World”. Although it’s very basic, this example will help us examine the basic structures necessary to create AppImages.

Go ahead and check out the hello-world-appimage directory for the code. In this repository:

• The file starts up the file.
• is the actual application that prints “Hello World!”
• The file sets the name of the application to and the icon to . Notably, other entries found in desktop files (such as ) are unnecessary for our purposes, and we’ve left them out.
• is the application icon.

Next, download the source code for the “Hello World” application.

git clone https://github.com/boolean-world/appimage-resources
cd appimage-resources

Then, we’ll build the AppImage from the contents of this directory. Replace the path below with the actual location where you’ve saved .

/path/to/appimagetool-x86_64.AppImage hello-world-appimage/

You’ll find that an executable named has been created. When you run this file, you’ll get the expected output of “Hello World!”.

In the next section, we’ll look at practical examples of building AppImages.

AppImage Format overview

An AppImage is an ISO 9660 file with zisofs compression containing a minimal AppDir (a directory that contains the app and all the files that it requires to run which are not part of the targeted base operating systems) and a tiny runtime executable embedded into its header. Hence, an AppImage is both an ISO 9660 file (that you can mount and examine) and an ELF executable (that you can execute).

When you execute an AppImage, the tiny embedded runtime mounts the ISO file, and executes the app contained therein.

A minimal AppImage could potentially look like this:

• AppRun is the binary that is executed when the AppImage is run
• .DirIcon contains a svg icon that is used for the AppImage
• SomeAppFile could be some random file that the app requires to run

However, in order to allow for automated generation, processing, and richer metadata, the AppImage format follows a somewhat more elaborate convention:

• The ELF embedded in the ISO9660 header always executes the file called which is stored inside the ISO9660 file.
• The file inside the ISO9660 file is not the actual executable, but instead a tiny helper binary that finds and exectues the actual app. Generic files have been implemented in bash and C as parts of AppImageKit. The C version, , is generally preferred as it is faster and more portable.
• AppRun usually does not contain hardcoded information about the app, but instead retrieves it from the file that follows the Desktop File Specification.

A minimal appname.desktop file that would be sufficient for AppImage would need to contain

This desktop file would tell the executable to run the executable called , and would specify as the name for the AppImage, and as its icon.

However, it does not hurt if the desktop file contains additional information. Should it be desired to provide additional metadata with an AppImage, the desktop file could be extended with fields as per the Desktop File Specification. Usually, desktop files provided in deb or rpm archives are suitable to be used in AppImages. However, absolute paths in the statement are not supported by the AppImage format.

The AppImage contains the usual hierarchy (following the File Hierarchy Standard). In the concrete example from the desktop file above, the AppRun executable would look for and would execute that. Also, AppImageKitAssistant (a tool used to create AppImages easily) would look for an icon and use that as the file, effectively making it the icon of the AppImage.

The app must be programmed in a way that allows for relocation. In other words, the app must not have hardcoded paths such as , , inside the binary. Instead, it must use relative paths, such as .

Since most binaries contained in deb and rpm archives generally are not created in a way that allows for relocation, they need to be either changed and recompiled (e.g., using the binreloc framework), or the binaries need to be patched. As recompiling is not convenient in most cases, AppRun changes to the directory prior to executing the app, enabling the app to specify all paths relative to the AppImage’s directory. This allows one to use patched binaries (where the string has been replaced with the same-length string , which means «current directory»). Note that if you use the patch, then your app must not use chdir, or otherwise it will break.

Note that the AppImage format has been conceived to facilitate the conversion of deb and rpm packages into the AppImage format with minimal manual effort. Hence, it contains some conventions in addition to those specified by the AppDir format, to which it is compatible to the extent that an unpacked AppImage can be used as an AppDir with the ROX Filer.

С Haiku все становится потрясающе простым

Хотя наивный подход к «переносу» AppImage на Haiku заключается в простой попытке сборки (в основном runtime.c и сервиса) его компонентов (что может быть даже и возможно!), это не принесет особой пользы для Haiku. Потому что на самом деле большинство этих проблем решено на Haiku и концептуально обоснованно. Haiku предоставляет именно те кирпичики для системной инфраструктуры, которые я так долго искал в рабочих окружениях на Linux и не мог поверить, что их там нет. А именно:

Верите или нет, но это не могут побороть многие пользователи Linux. На Haiku все делается автомагически!

• Файлы ELF, не имеющие бита исполнимости, получает его автоматически при двойном щелчке в файловом менеджере.
• Приложения могут иметь встроенные ресурсы, к примеру иконки, которые отображаются в файловом менеджере. Не нужно копировать кучу изображений в особые каталоги с иконками, а следовательно, не надо их подчищать после удаления или перемещения приложения.
• Есть база данных для связывания приложений с документами, нет необходимости копировать какие-либо файлы для этого.
• В каталоге lib/ рядом с исполняемым файлом библиотеки ищутся по-умолчанию.
• Нет многочисленных дистрибутивов и окружений рабочего стола, все что работает — работает везде.
• Не существует отдельного модуля для запуска, который отличался бы от каталога Applications.
• В приложениях нет встроенных абсолютных путей к своим ресурсам, есть специальные функции для определения местоположения во время исполнения.
• Внедрена идея сжатых образов файловых систем: это любой пакет hpkg. Все они монтируются ядром.
• Каждый файл открывается приложением, которое его создало, если явно не указать что-то иное. Как же это круто!

Два файла png

Обратите внимание на разные иконки, показывающие, что они будут открываться разными приложениями по двойному щелчку. Также обратите внимание на выпадающее меню «Открыть с помощью:», где пользователь может выбрать отдельное приложение

Как просто!

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

Описание

Цели

AppImage стремится стать системой запуска приложений для Linux со следующими целями: простота, двоичная совместимость, независимость от дистрибутива, запуск без установки, запуск без прав суперпользователя, переносимость и сохранение операционной системы нетронутой.

Свойства

AppImage не подразумевает под собой установку в привычном смысле этого слова. AppImage не размещает файлы приложения по системным папкам, а использует один сжатый файл. При запуске файла, он монтируется под FUSE. Это поведение сохранялось с самого начала существования проекта, и ранее использовалось в klik и PortableLinuxApps.

Каждое приложение самодостаточно: оно включает в себя все библиотеки, от которых зависит приложение. Стандарт AppImage 1.0 представлял собой iso-образ стандарта Rock Ridge (zisofs), включая в себя минимальный и небольшую библиотеку среды выполнения. Вторая версия может использовать другие файловые системы, такие как SquashFS.

AppImage и RISC OS

В 1988 году компания Acorn Computers выпустила операционную систему RISC OS 2.00, предназначенную для компьютеров собственного производства. Кроме идеи файлов как логического центра графического интерфейса, операционка предлагала еще одну интересную концепцию под названием AppDir: любое приложение представляло собой специальный каталог, имя которого начиналось с восклицательного знака. При виде такого каталога файловый менеджер автоматически принимал его за исполняемый файл, а при клике — запускал файл !Run, расположенный внутри. Позже эту идею сперли создатели NEXTSTEP, но гораздо более интересным для нас является тот факт, что она же была реализована в файловом менеджере ROX-Filer (имя которого так и расшифровывается — RISC OS on X).

Создатели ROX лишь немного изменили первоначальную идею, заменив имя файла !Run на AppRun, файла !Sprites — на .DirIcon, выкинули из названия восклицательный знак и добавили вместо него расширение .appdir. Все это без изменений перекочевало в AppImage и обзавелось обязательным .desktop-файлом.

Что внутри?

Попробовав портативные приложения в деле, постараемся разобраться, как они работают и чем отличаются от обычных дистрибутивных пакетов вроде Deb и RPM. Сами создатели AppImage не особо заботятся о документировании своей технологии, говоря только о том, что приложения упакованы в обычный ISO-образ, который включает в себя программу и все ее зависимости, поэтому дальнейшие изыскания придется проводить самостоятельно.

Упакованная по правилам AppImage программа действительно представляет собой ISO-образ. Это легко проверить, если набрать команду mount сразу после запуска приложения и посмотреть на последнюю строчку. В начало образа (а точнее, прямо перед ним) записана небольшая программа (назовем ее загрузчиком), которая монтирует образ к временному каталогу (с помощью того самого fuse) и запускает содержащийся внутри скрипт AppRun, который запускает саму программу. Именно благодаря загрузчику AppImage-приложение можно запустить сразу после скачивания, необходимости в распаковке нет.

Во всем остальном это самый обычный ISO-образ, который можно смонтировать, чтобы изучить содержимое:

Что мы видим внутри? Во-первых, корневой скрипт AppRun, который запускается загрузчиком сразу после монтирования ISO-образа. Его задача — подготовить приложение к работе и передать ему управление.

Содержимое Apprun

Эти три строки присваивают переменной окружения OPERA_DIR значение «/текущийкаталог/share/opera» и запускают программу из каталога «/текущийкаталог/lib/opera». Очевидно, OPERA_DIR указывает на каталог с ресурсами приложения, поэтому браузер использует его вместо стандартного «/usr/share/opera». Скорее всего, в случае многих других приложений скрипту AppRun пришлось бы использовать более хитрые приемы, чтобы переопределить дефолтовый каталог и обмануть приложение (например, символические ссылки), но здесь все просто. Следующий стандартный компонент AppImage — это файл opera-browser.desktop, содержащий метаданные приложения, такие как имя, путь к иконке (в данном случае — opera-browser.png), категории, к которым относится приложение, комментарии, типы ассоциированных с приложением файлов и т.д. (все в соответствии со стандартами freedesktop). Сама иконка программы дополнительно продублирована в скрытом файле .DirIcon. Остальное содержимое образа — компоненты самого приложения.

В данном случае это файлы LICENSE, install, opera-widget-manager и каталоги share и lib, представляющие собой локальную версию каталогов /usr/share и /usr/lib. Первый содержит все необходимые приложению ресурсы, документацию, man-страницы, второй — библиотеки зависимостей и сам исполняемый файл. У Opera зависимостей мало (разработчики компилируют ее статически, включая в бинарник даже библиотеку Xlib для работы с X Window), поэтому каталог lib почти пуст, только парочка библиотек самой программы и два плагина для Gstreamer. В целом, изнутри все выглядит довольно логично и просто, поэтому можно предположить, что и создавать такие образы будет легко.

Установка программ с помощью tasksel

Инструмент tasksel разработан специально для Debian. Он позволяет устанавливать пакеты группами. Разработчики сгруппировали пакеты в зависимости от их предназначения и вы можете установить одну из нужных групп. Именно эта утилита используется в установщике Debian.

Чтобы посмотреть список доступных групп наберите:

Также вы можете посмотреть какие пакеты находятся в группе:

Или описание группы пакетов:

Чтобы установить группу пакетов, например, веб-сервера, выполните:

А для удаления группы:

Установка программ Debian таким способом достаточно проста, но здесь есть не так много пакетов.

История

klik

klik запускает приложение

Изначально AppImage предшествовал klik, разработанный в 2004 году Симоном Питером (англ. Simon Peter) Приложение на клиентской стороне было лицензировано по GPL. klik интегрировался в браузер, пользователи могли скачивать и устанавливать приложение, просто введя ссылку, начинающуюся с . Это действие запускало процесс загрузки «рецепта» — файла, который помогал генерировать файл формата .cmg. В основном для генерации использовались файлы формата .deb из репозитория Debian Stable, таким образом достигалось покрытие большинства платформ при использовании одного файла-«рецепта». klik умел запускать не более 8 программ одновременно, так как существовало ограничение ядра Linux, не дававшее подключать более 8 образов одновременно. Обойти такое ограничение можно было, используя FUSE. Образы переподключались при каждом запуске, не оставляя за собой ничего, поэтому удалить программу можно было всего лишь удалив файл .cmg. Вторая версия klik была призвана исправить проблему множественных подключений, но, к сожалению, не вышла даже из стадии бета. К 2011 году проект был заморожен и домашняя страница ушла в офлайн.

PortableLinuxApps

Симон Питер запустил проект PortableLinuxApps, преследуя похожие цели:

AppImage

Около 2013 года продукт было решено переименовать в AppImage и изменить лицензию на MIT. Формат и спецификация теперь имеют конкретную реализацию, которая выложена в открытый доступ.

Заключение

Для Haiku есть инфраструктура, предоставляющая простой и утонченный пользовательский интерфейс для ПК, и далеко выходящая за рамки того, что обычно предоставляется для ПК на Linux. Система пакетов — один из таких примеров, но остальные части системы также пропитаны утонченностью. Тем не менее, от правильной поддержки каталогов и образов приложений Haiku бы выиграла. Как это лучше всего сделать — стоит обсудить с людьми, знающими Haiku, ее философию и архитектуру намного лучше, чем я. В конце концов я пользуюсь Haiku чуть больше недели. Но тем не менее, я считаю, что этот свежий взгляд окажется полезен дизайнерам, разработчикам и архитекторам Haiku. По крайней мере, я с радостью побуду для них «спарринг-партнером». У меня более 10 лет практического опыта работы с каталогами и комплектами приложений для Linux, и мне хотелось бы найти им применение для Haiku, для концепции которой, по моему мнению, они подходят идеально. Предложенные мною потенциальные решения вовсе не являются единственно верными для проблем, которые я описал, и если команда Haiku решит найти другие, более изящные, — я только всеми руками за. В принципе, я уже обдумываю идею того, как сделать систему еще более удивительной, не меняя способа ее работы. Оказывается, команда Haiku давно думала о комплектах приложений при внедрении системы управления пакетами, но к сожалению, (мне кажется) идея ушла в «устаревшие». Может быть, пришло время возродить ее?

Попробуйте сами! Ведь проект Haiku предоставляет образы для загрузки с DVD или USB, формируемые ежедневно.
Появились вопросы? Приглашаем вас в русскоязычный telegram-канал.

Обзор ошибок: Как выстрелить себе в ногу в C и C++. Сборник рецептов Haiku OS

От автора перевода: это восьмая статья из цикла про Haiku.