TL;DR: может ли Haiku получить надлежащую поддержку пакетов приложений, к примеру каталогов приложений (как .app в Mac) и/или образов приложений (Linux AppImage)? Мне кажется, это будет достойным дополнением, которое правильно внедрить проще, чем в других системах, поскольку большая часть инфраструктуры уже есть.

Неделю назад я открыл для себя Haiku, неожиданно хорошую систему. Ну а поскольку я давно интересуюсь каталогами и образами приложений (вдохновленными простотой Macintosh), то неудивительно, что мне в голову пришла идея…

Для полного понимания: я создатель и автор AppImage, формата распространения приложений Linux, нацеленного на простоту Mac и предоставляющего полное управление авторам приложений и конечным пользователям (хотите знать больше — см. wiki и документацию).

Что если мы сделаем AppImage для Haiku?

Давайте немного, чисто теоретически, порассуждаем: что нужно сделать для того, чтобы получить AppImage, или нечто подобное, на Haiku? Необязательно создавать что-то прямо сейчас, ведь система, которая уже есть в Haiku, работает удивительно, а вот воображаемый эксперимент получился бы неплохой. А еще он демонстрирует утонченность Haiku, по сравнению с рабочими окружениям Linux, где подобные вещи ужасно трудны (имею право так говорить: 10 лет уже маюсь с отладкой).

На Macintosh System 1 каждое приложение было отдельным файлом, "управляемым" в Finder. Используя AppImage я пробую пересоздать этот же пользовательский опыт на Linux.

Во-первых, а что такое AppImage? Это система для выпуска приложений сторонних разработчиков (к примеру, Ultimaker Cura), позволяющая выпускать приложения, когда и как им охота: не нужно знать особенности различных дистрибутивов, политик сборки или инфраструктуры сборки, не нужна поддержка сопровождающих, и они не указывают пользователям, что (не)можно устанавливать у себя на компьютерах. AppImage следует понимать как что-то, похожее на пакет для Mac в формате .app внутри образа диска .dmg. Основное отличие в том, что приложения не копируются, а остаются внутри AppImage всегда, примерно так же, как пакеты Haiku .hpkg монтируются, и никогда не устанавливаются в обычном смысле.

AppImage за более чем 10 лет существования получил некоторую притягательность и популярность: сам Линус Торвальдс публично одобрил его, а распространенные проекты (к примеру, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) приняли его в качестве основного способа распространения непрерывных или ночных сборок, не мешающих установленным или не установленным приложениям пользователей. Однако рабочие окружения и дистрибутивы Linux чаще всего по-прежнему цепляются за традиционную, централизованную модель распространения на основе сопровождающих и/или продвигают собственные корпоративные бизнес и/или инженерные программы на основе Flatpak (RedHat, Fedora, GNOME) и Snappy (Canonical, Ubuntu). Доходит до смешного.

Как все работает

Каждый AppImage содержит в себе 2 части: маленький исполняемый по двойному щелчку ELF (т.наз. runtime.c), с последующим образом файловой системы SquashFS.

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

При запуске пользователем runtime использует FUSE и squashfuse для монтирования файловой системы, после чего обрабатывает запуск некоторой точки входа (т.н. AppRun) внутри смонтированного AppImage.
Файловая система размонтируется после того, как завершится процесс.

Вроде все просто.

А эти вещи все усложняют:

с таким разнообразием дистрибутивов Linux уже ничто «в здравом уме» не назовешь "частью установки по-умолчанию для каждой свежей целевой системы". Мы обходим эту проблему путем сборки excludelist, позволяющего определить, что будет упаковано в AppImage, а что нужно будет взять где-то еще. При этом мы иногда промахиваемся, несмотря на то, что в общем-то все отлично работает. По этой причине мы рекомендуем создателям пакетов проверять AppImages на всех целевых системах (дистрибутивах).
Приложения в виде полезной нагрузки должны быть перемещаемыми по файловой системе. К сожалению, в многих приложениях жестко заданы абсолютные пути к, например, ресурсам в /usr/share. Это надо как-то исправлять. Помимо этого надо либо экспортировать LD_LIBRARY_PATH, либо исправлять rpath для того, чтобы загрузчик мог найти связанные библиотеки. У первого способа есть свои недостатки (которые обходятся сложными способами), а второй просто громоздкий.
Самая большая UX ловушка для пользователей в том, что надо установить исполняемый бит файлу AppImage после скачивания. Хотите верьте, хотите нет, но для кого-то это реальный барьер. Необходимость установки бита исполняемости громоздка даже для опытных пользователей. В качестве обходного пути мы предложили установку небольшого сервиса, следящего за файлами AppImage и устанавливающего им бит исполнимости. В чистом виде, не самое лучшее решение, поскольку не будет работать "из коробки". Дистрибутивы Linux не поставляют этот сервис, следовательно, у пользователей "из коробки" все плохо.
Пользователи Linux ждут, что у нового приложения появится иконка в меню запуска. Системе не скажешь: «Смотри, вон новое приложение, давай работай". Вместо этого, согласно спецификации XDG, надо скопировать файл .desktop в нужное место в /usr для общесистемной установки, или в $HOME для индивидуальной. Иконки определенных размеров, согласно спецификации XDG, нужно поместить в определенные места в usr или $HOME, после чего запустить команды в рабочем окружении для обновления кэша иконок, или надеяться, что менеждер рабочего окружения сообразит и автоматически все обнаружит. Аналогично с типами MIME. В качестве обходного способа предлагается использовать тот же сервис, который помимо установки признака исполнимости будет, при наличии иконок и проч. в AppImage, копировать их из AppImage в нужные места согласно XDG. При удалении или перемещении сервис предполагаемо будет зачищать все. Конечно, есть различия в поведении у каждого рабочего окружения, в форматах графических файлов, их размерах, местах хранения и способах обновления кэшей, что и рождает проблему. Короче, этот способ — костыль.
Если вышеперечисленного недостаточно, в файловом менеджере так и нет иконки AppImage. В мире Linux до сих пор не приняли решение о внедрении elficon (несмотря на обсуждение и реализации), так что невозможно встроить иконку прямиком в приложение. Вот и получается, что приложения в файловом менеджере не имеют собственных иконок (без разницы, AppImage или что-то другое), они есть только в меню запуска. В качестве обходного пути мы применяем миниатюры — механизм, который изначально был разработан для того, чтобы менеджеры рабочего стола могли показывать уменьшенные изображения для предпросмотра графических файлов в качестве их иконок. Следовательно, сервис для установки бита исполнимости также работает как "миниатюризатор", создавая и записывая миниатюры иконок в соответствующие места /usr и $HOME. Также этот сервис выполняет зачистку если AppImage удаляется или перемещается. Из-за того, что каждый менеджер рабочего стола ведет себя чутка по-разному, к примеру, в каких форматах принимает иконки, в каких размерах или местах, это все реально болезненно.
Приложение просто падает при исполнении, если возникают ошибки (к примеру, есть библиотека, которая не является частью базовой системы и не поставляемая в AppImage), и никто не говорит пользователю в GUI о том, что именно происходит. Мы начали обходить это, используя уведомления на рабочем столе, а значит, нам надо вылавливать ошибки из командной строки, преобразовать их в понимаемые пользователю сообщения, которые потом надо еще отобразить на рабочем столе. И конечно же, каждое рабочее окружение обрабатывает их немножко по-разному.
На текущий момент (сентябрь 2019 года, — прим. переводчика) я не нашел простого пути сказать системе, что файл 1.png надо открывать с помощью Krita, а 2.png — с помощью GIMP.

Местом хранения cross-desktop спецификаций, используемых в GNOME, KDE и Xfce является freedesktop.org

Достижение уровня утонченности, глубоко вплетенного в рабочее окружение Haiku, затруднено, если не сказать «невозможно», из-за спецификаций XDG от freedesktop.org для cross-desktop, а также реализаций менеджеров рабочего стола на основе этих спецификаций. В качестве примера можно привести одну общесистемную иконку Firefox: видимо, авторам XDG и в голову не пришло, что у пользователя может быть установлено несколько версий одного и того же приложения.

Иконки разных версий Firefox

Мне было интересно, чему мир Linux мог бы научиться у Mac OS X, чтобы не лажать при системной интеграции. Если у вас есть время и вы занимаетесь таким — обязательно почитайте, что сказал Арно Гурдол, один из первых инженеров Mac OS X:

Мы хотели, чтобы установить приложение было так же просто, как перетащить иконку приложения откуда-нибудь (сервер, внешний диск) на диск вашего компьютера. Для этого в пакете приложения сохранена вся информация, включая иконки, версию, обрабатываемый тип файла, тип схем URL, которую система должна знать для обработки приложения. Сюда же относится информация для 'централизованного хранения' в базе данных Icon Services и Launch Services. Для поддержки производительности приложения 'обнаруживаются' в нескольких 'хорошо известных' местах: в системном и пользовательском каталоге Applications, а также в некоторых других автоматически, если пользователь перешел в Finder в каталог, содержащий приложение. На практике это очень хорошо сработало.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 сессия 144 — Mac OS X: упаковка приложений и распечатка документов.

Ничего подобного из этой инфраструктуры нет на рабочих окружениях Linux, поэтому мы ищем обходные пути вокруг структурных ограничений в проекте AppImage.

Неужто Haiku спешит на помощь?

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

Мой доклад по проблемам рабочих окружений Linux в 2018

Даже Линус Торвальдс признал, что именно из-за фрагментации идея рабочих окружений не удалась.

Приятно видеть Haiku!

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

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

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

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

Два файла png. Обратите внимание на разные иконки, показывающие, что они будут открываться разными приложениями по двойному щелчку. Также обратите внимание на выпадающее меню "Открыть с помощью:", где пользователь может выбрать отдельное приложение. Как просто!

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

Нужны ли Haiku пакеты приложений, в конце концов?

Это подводит к большому вопросу. Если бы на Haiku создать систему вроде AppImage оказалось на порядок проще, чем на Linux, стоило бы этим заняться? Или же Haiku с ее системой пакетов hpkg фактически устранила необходимость разработки подобной идеи? Что ж, для ответа надо взглянуть на мотивацию существования AppImages.

Взгляд со стороны пользователя

Посмотрим на нашего конечного пользователя:

Я хочу поставить приложение без запроса пароля администратора (root). На Haiku нет понятия администратора, у пользователя полный контроль, поскольку это персональная система! (В принципе, можно представить это и в многопользовательском режиме, надеюсь, разработчики сохранят простоту)
Я хочу получать последние и лучшие версии приложений, не ждать, когда они появятся в моём дистрибутиве (чаще всего это значит "никогда", по крайней мере, если не обновить всю операционку). На Haiku это "решено" с помощью плавающих выпусков. Это означает, что есть возможность получать последние и лучшие версии приложений, но для этого нужно постоянно обновлять и остальную часть системы, фактически превращая ее в "движущуюся цель".
Мне хочется несколько версий одного и того же приложения рядом, поскольку нельзя узнать, что было сломано в последней версии, или, допустим, мне, как веб-разработчику, надо проверить свою работу под разными версиями браузера. В Haiku решена первая, но не вторая проблема. Обновления откатываются, но только для системы целиком, невозможно (как мне известно) запустить, к примеру, несколько версий WebPositive или LibreOffice одновременно.

Один из разработчиков пишет:

По сути, обоснование такое: сценарий использования настолько редкий, что оптимизация для него не имеет смысла; обработка его, как особого случая, в HaikuPorts, кажется более чем приемлемой.

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

Комментарий разработчика:

Технически, это уже возможно с командой mount. Конечно, мы сделаем GUI для этого, как только наберется достаточно заинтересованных пользователей.

Мне не нужны миллионы файлов, разбросанных по файловой системе, которыми я не могу самостоятельно вручную управлять. Хочу один файл на приложение, который я могу легко скачать, переместить, удалить. На Haiku эта проблема решена с помощью пакетов .hpkg, которые переносят, к примеру python, из тысяч файлов в один. Но если есть, к примеру, Scribus, использующий python, то мне приходится иметь дело минимум с двумя файлами. И я должен позаботиться о том, чтобы сохранить их работающие друг с другом версии.

Многочисленные версии AppImages, запущенный рядом на одном Linux

Взгляд со стороны разработчика приложений

Давайте посмотрим с точки зрения разработчика приложений:

Я хочу управлять пользовательским опытом целиком. Не хочу зависеть от операционной системы, которая будет мне указывать, когда и как я должен выпускать приложения. В Haiku разработчикам можно работать со своими собственными репозиториями hpkg, но это означает, что пользователям надо будет настраивать их вручную, что делает эту идею "менее привлекательной".
У меня есть страница загрузки на моем веб-сайте, где я распространяю .exe для Windows, .dmg для Mac и .AppImage для Linux. А может, я захочу монетизировать доступ к этой странице, все может быть? Что мне надо разместить там для Haiku? Достаточно файла .hpkg с зависимостями только от HaikuPorts
Моему ПО нужны определенные версии другого ПО. К примеру, известно, что для Krita нужна исправленная версия Qt, или Qt, которая точно настроена на конкретную версию Krita, по крайней мере, до тех пор, пока исправления не вернутся обратно в Qt. Можно упаковать собственный Qt для приложения в пакете .hpkg, но скорее всего, такое не приветствуется.

Обычная страница загрузки приложения. Что же разместить здесь для Haiku?

Станут ли комплекты (существующие в виде каталогов приложений, как AppDir или .app в стиле Apple) и/или образы (в виде сильно модифицированных AppImages или .dmg от Apple) приложений полезным дополнением для рабочего окружения Haiku? Или это разбавит целостную картину и приведет к фрагментации, а следовательно, добавит сложности? Я разрываюсь: с одной стороны, красота и утонченность Haiku основаны на том, что обычно есть один способ сделать что-то, а не много. С другой стороны, большая часть инфраструктуры для каталогов и/или комплектов приложений уже на месте, поэтому система взывает к тому, чтобы на свои места встали и оставшиеся несколько процентов.

Согласно разработчику mr. waddlesplash

На Linux они (каталоги и комплекты приложений, — прим. переводчика) скорее всего являются техническим решением системных проблем. На Haiku мы предпочитаем просто решать системные проблемы.

А вы что думаете?

Прежде чем ответите...

Подождите, сделаем быструю проверку на реальность: по факту каталоги приложений — уже часть Haiku:

Каталоги приложений уже существуют на Haiku, но пока не поддерживаются в файловом менеджере

Они просто не так хорошо поддерживаются, как, скажем, в Macintosh Finder. Насколько было бы круто, если бы каталог QtCreator имел бы в верхнем левом углу имя и иконку "QtCreator", запускающие приложение по двойному щелчку?

Немного ранее я уже спрашивал:

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

Имеется ли уже ответ со стороны Haiku, или каталоги и комплекты приложений смогут тут помочь? Я думаю, смогут.

Согласно mr. waddlesplash:

Да, у нас есть ответ на вопрос: мы просто будем поддерживать эти приложения столько, сколько нужно, пока кто-нибудь не сможет правильным способом прочитать их форматы файлов или обеспечить функциональность один к одному. Наше стремление поддерживать работу приложений BeOS R5 на Haiku — прямое тому доказательство...

Это точно!

Какой план действий должна принять Haiku?

Я могу представить мирное сосуществование hpkg, каталогов и образов приложений:

Системное ПО использует .hpkg
Для наиболее часто используемого ПО (особенно для того, которому надо запланировать плавающие выпуски) используется .hpkg (примерно 80% всех случаев)
Некоторые, установленные через .hpkg, приложения выиграют при переходе на инфраструктуру с каталогами приложений (к примеру, QtCreator): они будут распространяться в виде .hpkg, как и раньше.

mr. waddlesplash пишет:

Если все, что нужно, это — просмотр приложений в /system/apps, вместо этого надо сделать каталоги в Deskbar более управляемыми для пользователей, поскольку /system/apps не предназначен для того, чтобы пользователи регулярно открывали и смотрели его (в отличие от MacOS). Для таких ситуаций у Haiku другая парадигма, но этот вариант, по идее, приемлем.

Haiku получает инфраструктуру для запуска образов приложений, ночных, непрерывных и тестовых сборок ПО, а также на случаи, когда пользователь желает его "заморозить во времени", для частного и внутреннего ПО, и других особых случаев использования (около 20% от всех). Эти образы содержат необходимые для запуска приложения файлы .hpkg, монтируемые средствами системы, а после завершения приложения — размонтируемые. (Возможно, файловый менеджер мог бы помещать файлы .hpkg в образы приложений, автоматически или по требованию пользователя — ну, как когда перетаскиваешь приложение на сетевой каталог или внешний диск. Это же просто песня! А точнее поэзия — хайку.) С другой стороны, пользователь может захотеть установить содержимое образа в виде файлов.hpkg, после чего они будут обновляться и обрабатываться точно также, как если бы были установлены через HaikuDepot… Надо провести мозговой штурм).

Цитата от mr. waddlesplash:

Запуск приложений с внешних дисков или сетевых каталогов потенциально может быть полезным. А добавление возможности настройки большего количества "зон" для pkgman определенно станет хорошей функцией.

Подобная система будет использовать преимущества hpkg, каталогов и образов приложений. Они хороши и по отдельности, но вместе станут непобедимы.

Заключение

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

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

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

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

Список статей: Первая Вторая Третья Четвертая Пятая Шестая Седьмая Восьмая Девятая

Кое-что еще: пакеты приложений Haiku?