СофтХабрахабр

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

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

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

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

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

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

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

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

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

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

  • Каждый 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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Мне не нужны миллионы файлов, разбросанных по файловой системе, которыми я не могу самостоятельно вручную управлять. Хочу один файл на приложение, который я могу легко скачать, переместить, удалить. На 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 основаны на том, что обычно есть один способ сделать что-то, а не много.

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

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

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

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

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


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

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

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

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

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

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

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

Это точно!

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

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

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

waddlesplash пишет: mr.

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

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

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

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

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

Заключение

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»