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

[Перевод] Мой шестой день с Haiku: под капотом ресурсов, иконок и пакетов

Но как оно работает? TL;DR: Haiku — операционная система, специально разработанная для ПК, поэтому у нее есть несколько хитростей, делающих ее рабочее окружение намного лучше других.

До сих пор поражен тем, как гладко она работает, особенно по сравнению с рабочими окружениями на Linux. Недавно я открыл для себя Haiku, неожиданно хорошую систему. Там, где это будет нужно для углубленного понимания, я проведу сравнение с оригинальным Macintosh, Mac OS X и рабочими окружениями Linux (стандарт XDG от freedesktop.org). Сегодня я загляну под капот.

Ресурсы в файлах ELF

Сегодня хочу посмотреть, как оно работает на самом деле. Вчера я узнал, что IconOMatic умеет сохранять иконки в ресурсах rdef в исполняемых файлах ELF.

Цитата от Брюса Хорна, изначального автора программы Macintosh Finder и "отца" Macintosh Resource Manager: Ресурсы?

Для меня сама идея приложения, замороженного в коде, без возможности изменить что-либо динамически — дичайшая дикость. Меня беспокоит жесткий характер традиционного написания кода. Разумеется, сам код приложения не может быть изменен, но ведь что-то можно поменять и без перекомпиляции кода? Должна быть возможность изменять как можно больше на этапе времени исполнения.

в исполняемых файлах. На оригинальном Macintosh сделали так, что у этих файлов есть "секция данных" и "секция ресурсов", что необычайно облегчило сохранение различных вещей, к примеру иконок, переводов и т.п.

На Maс для этого применяется ResEdit, графическая программа для — внезапно — редактирования ресурсов.


ResEdit на оригинальном Macintosh

достаточно легко, однако они все равно "путешествуют" с приложениями.
В любом случае этот подход имел большой недостаток: работал только на файловых системах Apple, что стало одной из причин почему Apple отказалась от "секции ресурсов" при переходе на Mac OS X.
На Mac OS X Apple хотели решения, независимого от файловой системы, поэтому применили концепцию пакетов (из NeXT), каталогов, которые обрабатываются файловым менеджером как "непрозрачные объекты", подобно файлам, а не каталогам. В результате появилась возможность редактировать иконки, пункты меню, переводы и проч. Любой пакет с приложением в формате .app имеет, среди прочего, файл Info.plist (в некоем аналоге JSON или YAML от Apple), содержащий метаданные приложения.


Ключи файла Info.plist из пакета приложения Mac OS X.

Концепция фактически вернулась обратно к истокам в NeXT. Ресурсы, к примеру иконки, файлы UI и прочие, хранятся в пакете в виде файлов.

0 в 1989 году: отображается как каталог с файлами в терминале, но как единый объект в графическом файловом менеджере.
Mathematica.app на NeXTSTEP 1.

Её разработчики при переходе с PEF (PowerPC) на ELF (x86) (тот же, что применяется на Linux) решили добавить секцию ресурсов в конец файлов ELF. Вернемся к BeOS, на концепциях которой основана Haiku. В результате программы strip и прочие из binutils, не знающие о таком, просто обрезали ее. Для этого не использовалась собственная надлежащая секция ELF, ее просто дописывали в конец файла ELF. Поэтому, добавив ресурсы в файл ELF на BeOS, лучше не работать с ним инструментами Linux.

В принципе, более-менее то же самое. А что же происходит сейчас с Haiku?

Согласно разработчикам на канале #haiku в сети irc.freenode.net: В теории можно было бы размещать ресурсы в нужной секции ELF.

С ELF секция имела бы больше смысла … единственная причина, по которой мы так не поступаем, — так делали в BeOS"
И изменять это сейчас не стоит.

Управление ресурсами

Вспомнился формат ar.
Как же проверить ресурсы в Haiku? Ресурсы пишутся в структурированном "ресурсном" формате: по сути это список ресурсов с размерами и потом уже их содержимое. Есть что-то типа ResEdit?
Согласно документации:

Также можно зайти в терминал и запустить команду listres имя_файла. Для просмотра ресурсов, поставляемых в пакете приложения, можно перетянуть исполняемый файл на программу типа Resourcer.

Resourcer есть в HaikuDepot, но у меня он просто падает.

Используя rsrc и rdef. Как же управлять ресурсами в файлах ELF? Файл rdef хранится в обычном текстовом формате, так что работать с ним гораздо легче. rdef файлы собираются в rsrc. Давайте попробуем поиграть: Файл в формате rsrc дописывается в конец файла ELF.

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file: rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script: rc [options] [-o <file>] -d <file>...Options: -d --decompile create an rdef script from a resource file --auto-names construct resource names from ID symbols -h --help show this message -I --include <dir> add <dir> to the list of include paths -m --merge do not erase existing contents of output file -o --output specify output file name, default is out.xxx -q --quiet do not display any error messages -V --version show software version and license

Можно использовать программу xres для проверки и управления:

/> xres
Usage: xres ( -h | --help ) xres -l <file> ... xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

Ладно, давайте пробовать?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- -------------------- 'MIMS' 1 36 BEOS:APP_SIG 'APPF' 1 4 BEOS:APP_FLAGS 'MSGG' 1 421 BEOS:FILE_TYPES 'VICN' 101 7025 BEOS:ICON 'VICN' 201 91 kActionBack 'VICN' 202 91 kActionForward 'VICN' 203 300 kActionForward2 'VICN' 204 101 kActionStop 'VICN' 206 243 kActionGoStart 'MSGG' 205 1342 kActionGo 'APPV' 1 680 BEOS:APP_VERSION

Больше о ресурсах и формате rdef можно почитать здесь.

Стандартные типы ресурсов

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

  • app_signature: MIME тип приложения, для сопоставления открываемых файлов, запуска, IPC и т.п.
  • app_name_catalog_entry: Поскольку имя приложения обычно на английском, то здесь можно указать места, где лежат переведенные имена, так что пользователи разных языков будут видеть при желании переведенное имя приложения.
  • app_version: точно то, что вы подумали
  • app_flags: указывает registrar как обрабатывать приложение. Я думаю, есть что-то большее, чем оно кажется на первый взгляд. К примеру, есть B_SINGLE_LAUNCH, который заставляет систему запускать новый процесс приложения каждый раз, по запросу пользователя (такой же принцип используется для большинства приложений на Linux). Есть B_MULTIPLE_LAUNCH, заставляющий запускать процесс для каждого файла. Наконец есть B_EXCLUSIVE_LAUNCH, который заставляет систему запускать только один процесс одновременно, независимо от того, как часто пользователи его запускают (к примеру, так же запускается Firefox на Linux; того же результата можно добиться в приложениях Qt, используя функцию QtSingleApplication). Приложения с B_EXCLUSIVE_LAUNCH уведомляются, когда пользователь пробует запускать их повторно: к примеру, получают путь файла, который пользователь желает открыть с их помощью.
  • vector_icon: Векторная иконка приложения (В BeOS не было векторных иконок, большинство приложений вместо них имело по две растровые иконки в исполняемых файлах).

Но для начала давайте остановимся на увлекательной теме иконок. Конечно же, можно добавить ресурсы с любыми желаемыми ID и типами, после чего читать их в самом приложении или других приложениях с помощью класса BResources.

Векторные иконки в стиле Haiku

Разумеется не только Haiku выбрал лучший формат иконок, в этой части ситуация с рабочими окружениями Linux далека от идеальной:

me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cache

Глядя на такое уже можно почувствовать, чего это кусок.

Почему же тогда есть что-то еще? Конечно, есть scalable, содержащий, как можно понять, векторные иконки. Хочется иметь различные варианты, оптимизированные для разных размеров. Потому что результат отрисовки векторной графики в малых размерах может быть хуже идеального. В рабочих окружениях Linux это достигается рассыпанием по файловой системе иконок с разными размерами.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

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

Пока что невозможно обработать это в Linux без различных костылей.
Разные иконки Firefox в разных версиях.

Mac OS X обрабатывает чуть более утонченно:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

Иконки путешествуют вместе с приложением, все ресурсы в одном файле. Видно, что есть один файл firefox.icns в пакете Firefox.app, содержащий все размеры, так что разные версии одного приложения имеют разные иконки.
Намного лучше!

Умопомрачительное решение, без исключений. Вернемся к Haiku. Согласно документации:

Поэтому наши иконки по большей части намного меньше чем в растровом или в широкоприменяемом формате SVG. Был разработан особый, высокооптимизированный для малых размеров и быстрой отрисовки, формат HVIF.

И они таки оптимизированы:


Размеры иконки в HVIF по сравнению с другими форматами.

Разница на порядок!

Один и тот же HVIF может показать разные уровни детализации в зависимости от отображаемого размера, несмотря на то, что это векторый формат. Но магия здесь не заканчивается.


Разные уровни детализации (LOD) в зависимости от размера отрисовки

Тут пояснения. Теперь о недостатках: нельзя взять SVG, закинуть в ImageMagick и на этом закончить, надо пройти несколько циклов для создания иконки в формате HVIF. Почитать больше о том, как HVIF делает свою магию можно в блоге Леа Гэнсон Однако IconOMatic может достаточно несовершенно импортировать SVG; порядка 90% деталей SVG импортируется с некоторой вероятностью, остальные 10% надо будет настроить и поменять вручную.

Добавление иконки в приложение

Теперь я могу добавить иконку пакету, созданному в прошлый раз, с учетом всей полученной информации.
Ну а поскольку я сейчас не особо горю желанием рисовать собственную иконку для моего "Привет, Мир" QtQuickApp — выдергиваю ее из Qt Creator.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt\ Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt\ Creator

Давайте проверим, что иконка скопирована:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- -------------------- 'VICN' 101 152238 BEOS:ICON

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


Скопированная VICN:101:BEOS:ICONs пока не используется в качестве иконки для приложения в файловом менеджере

Что же я пропустил?

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

Потом надо выполнить команду resattr -o имя_бинарника имя.rsrc. Надо создать файл rdef со всеми ресурсами, потом выполнить команду rc имя.rdef, это создаст файл .rsrc. Как минимум, я использую подобные команды для добавления иконок к моим скриптам.

Я прямо растерян. Ну, хотелось же создать ресурс, а не атрибут.

Умное кэширование с использованием файловой системы

Как я уже писал выше, иконка пишется в качестве ресурса в самом файле. Открытие и чтение атрибутов ELF работает медленно. Однако потом он также копируется в атрибут файловой системы, к примеру BEOS:ICON. Этот способ надежнее, позволяет пережить копирование на другую файловую систему. Иконки, показываемые системой (в Tracker и Deskbar), читаются с этого расширенного атрибута, потому что подобное решение работает быстро. Это работает только на определенных файловых системах, к примеру BFS. Но это еще не конец. В некоторых местах (там, где скорость не важна, к примеру типовое окно "О программе") система получает иконку напрямую из ресурса в файле. На Haiku стоит воспринимать ресурс (в файле) в качестве исходной иконки, поставляемой с приложением, а атрибут (в файловой системе BFS) как нечто, позволяющее пользователю внести изменения по желанию (хотя, подсказка, графический интерфейс для вставки пользовательской иконки поверх иконки по-умолчанию пока еще не реализован). Помните, на Mac, пользователи могли заменить иконки приложений, каталогов, документов своими, поскольку на Mac есть возможность сделать эти "важные" вещи, к примеру замена новой иконки Slack на предыдущую.

Проверка атрибутов файловой системы

С помощью resaddr есть возможность проверить и установить атрибуты файловой системы.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ] Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

А поскольку система предполагает получение ресурсов и выполняет копирование автоматически, я не буду дальше об этом беспокоиться. По сути это "клей", выполняющий преобразование туда-сюда между (надежными) ресурсами и (быстрыми) атрибутами файловой системы.

Волшебство hpkg пакетов

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

Достаточно тяжело управляться с файлами (к примеру, удалить их), когда производится установка пакета традиционным способом. С традиционными форматами пакетов я долго расстраивался из-за такого вот факта: скачиваешь одно (пакет), а в системе устанавливается другое (файлы внутри пакета). Это же порождает целый класс программ — пакетных менеджеров. А все потому, что содержимое пакета рассыпается по всей файловой системе, включая места, куда обычный пользователь может не иметь доступа на запись. В обычной системе на основе Linux могут легко существовать от нескольких сотен тысяч до миллионов обособленных файлов. А ведь перенос уже установленного ПО, к примеру, на другую машину, съемный диск или файловый сервер становится даже труднее, а то и вовсе невозможным. Само собой разумеется, это одновременно и хрупко, и медленно, к примеру при первоначальной установке системы, при установке, обновлении и удалении обычных пакетов, а также при копировании загрузочного тома (корневого раздела) на другой носитель.

Это формат распространения ПО, собирающий приложение и все его зависимости в один образ файловой системы, монтируемый при запуске приложения. Я работаю над проектом AppImage, частичного костыля для приложений для конечных пользователей. Предложенный способ работает только для ПО, как отражено в имени проекта, а также имеет собственный набор болячек, поскольку люди, занимающиеся поставками ПО для Linux, всегда переводят стрелки на меня. Значительно упрощает вещи, поскольку тот же ImageMagick внезапно превращается в один файл, управляемый в файловом менеджере простыми смертными.

Получилось ли найти оптимальный баланс между традиционными пакетными системами и поставкой ПО на основе образов? Вернемся к Haiku. При загрузке системы ядро монтирует все установленные и активные пакеты примерно с следующими сообщениями ядра: Её пакеты .hpkg фактически сжатые образы файловой системы.

KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

Держитесь, дальше будет еще круче! Круто, да?

Есть очень особенный пакет:

KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Верите или нет, но даже ядро само по себе не извлекается из загрузочного тома (корневого раздела), а аккуратно загружается на свое место из пакета .hpkg. Он содержит весьма минималистичную операционную систему, включая ядро. Я уже упоминал о том, что, как по мне, часть общей утонченности и согласованности Haiku обусловлена тем, что вся система от ядра и базового пользовательского пространства, а также до управления пакетами и инфраструктурой рабочего окружения разрабатывается совместно одной командой. Вот это да! переводчика]. Представьте, сколько разных групп и команд потребуется для того, чтобы запустить подобное на основе Linux [представляю себе проект PuppyLinux, — прим. Говорят же: возьми простую задачу, раздели между разными исполнителями, и она так усложнится, что ее будет уже не решить. Затем представьте, сколько времени потребуется для того, чтобы этот подход был внедрен в дистрибутивы. Думаю, именно это и происходит на Linux сейчас (Linux в данном случае — собирательный термин, обозначающий стек Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu). Haiku в данном случае открыла мне глаза.

Откат системы с использованием hpkg

Если пользоваться обычными пакетными менеджерами, трудно вернуть состояние системы к моменту времени до установки новых пакетов (к примеру, в случае, когда что-то пошло не так). Как часто получается следующая ситуация: обновление прошло успешно, а потом выясняется, что что-то работает не так, как надо? В Haiku это решено с помощью пакетов .hpkg. Некоторые системы предлагают обходные пути в виде слепков файловой системы, но они достаточно громоздкие, а также применяются далеко не во всех системах. Незавершенные операции хранят свои данные в подкаталогах /Haiku/system/packages/administrative/transaction-<...>/. Всякий раз, когда меняются пакеты в системе, старые пакеты не удаляются, а хранятся в системе в подкаталогах вида /Haiku/system/packages/administrative/state-<...>/ постоянно.

Каталоги "state..." содержат текстовые файлы с именами активных пакетов, "transaction..." — сами пакеты.
Содержимое /Haiku/system/packages/administrative.

список .hpkg пакетов, активных перед изменениями, записывается после каждой операции в файловом менеджере в текстовом файле /Haiku/system/packages/administrative/state-<...>/activated-packages. "Старое активное состояние", т.е. Похожим образом пишется новое "активное состояние" в текстовом файле /Haiku/system/packages/administrative/activated-packages.

Каталог /Haiku/system/packages/administrative/state-<...>/ содержит только текстовый файл со списком активных пакетов этого состояния (в случае установки пакетов без удаления), а если пакеты удалялись или обновлялись — state каталог содержит старые версии пакетов.

Вот так вот просто! При загрузке системы на основе списка пакетов принимается решение об активации (монтировании) пакетов. Задача решена! Если при загрузке что-то пойдет не так — можно указать менеджеру загрузки использовать другой, более старый список.

Каждая точка входа отображает соответствующее "активное состояние"
Загрузочик Haiku.

Это резко контрастирует с созданной-для-машин-а-не-для-людей кучей от OSTree или Flatpak в файловой системе (по уровню там же, где и Microsoft GUID). Мне нравится подход с простыми текстовыми файлами в качестве списка "активного состояния", в которых записаны понятные для понимания имена .hpkg.


Список активных пакетов для каждого момента времени

Конфигурационные данные

Ведь, как помните, .hpkg монтируются только для чтения. Судя по всему, в каталоге /Haiku/system/packages/administrative/writable-files содержатся файлы настроек для пакетов, но доступные на запись. Имеет смысл. Таким образом, эти файлы должны быть скопированы из пакетов перед записью.

Интеграция GUI для системы .hpkg

Ведь Haiku предназначен для персонального применения, в конце концов. Давайте теперь посмотрим, как эти блестящие пакеты .hpkg справляются с интеграцией в пользовательское рабочее окружение (UX). Не буду даже сравнивать ситуацию с рабочими окружениями на Linux, потому что она абсолютно ужасная по сравнению с любыми другими. Лично я установил высокую планку, сравнивая пользовательский опыт с пакетами .app на Macintosh с таким же опытом на .hpkg.

На ум приходят следующие сценарии:

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

Ну, приступим. Это должно охватить большинство основных случаев из моей повседневной работы.

Проверка содержимого пакета

Ведь в действительности это просто замаскированный каталог! На Mac я просто щелкаю правой кнопкой по пакету для его открытия и просмотра содержимого в Finder. (Я знаю, что есть пакеты .pkg для части системы, которая не является приложениями, но обычные пользователи с ними чаще всего и не взаимодействуют).

Но здесь просто список файлов без возможности открыть их по двойному щелчку.
Было бы гораздо лучше, если бы имелся способ (временный) монтирования пакета .hpkg для просмотра через файловый менеджер, а пользователю не нужно было бы заботиться о деталях реализации. На Haiku я щелкаю правой кнопкой мыши по пакету, потом щелкаю по "Contents" для просмотра того, что внутри. (Между прочим, можно открыть .hpkg пакет в Expander, который может распаковать его как и любой другой архив).


В интерфейсе HaikuDepot можно просмотреть список файлов пакета, но нет способа просмотра содержимого, к примеру, дважды щелкнув по README.md

В этой категории Mac побеждает, но добавление нужной функциональности HaikuDepot не должно вызвать больших трудностей.

Установка пакета через GUI

Открываем двойным щелчком дисковый образ, после чего копируем пакет, к примеру, перетягивая его в /Applications в Finder. На Mac, большинство дисковых образов .dmg содержат пакеты .app. По-умолчанию Apple "предлагает" общесистемный каталог /Applications (на NeXT он был сетевой, а также индивидуальный), но можно легко поместить свои приложения на файловый сервер или в подкаталог $HOME/Applications, если вам так нравится. Для меня это само собой разумеется, но я слышал, что некоторые новички могут не осилить такое.

Мне вот интересно, а что произойдет, если у пакета есть зависимости, доступные в HaikuPorts, но пока еще не установленные. На Haiku, двойной щелчок по пакету, потом щелчок по "Install", проще некуда. Точно то, что делает Haiku. На Linux в самом деле не знают, что делать в этой ситуации, но ведь решение очевидно — спросить пользователя, нужно ли загрузить и установить зависимости.

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

А ведь концепция нескольких пользователей еще даже не доступна для Haiku (наверное, поэтому все так просто — я не знаю, может, многопользовательские возможности излишне усложнят вещи для рабочего окружения персонального компьютера). Еще один способ — использование файлового менеджера, достаточно перетянуть .hpkg пакет или в /Haiku/system/packages (для общесистемной установки, по-умолчанию), или в /Haiku/home/config/packages (для индивидуальной установки; недоступно при двойном щелчке — меня все еще раздражает слово "config" в этом месте, которое для меня в данном случае синоним "settings").

В этой категории побеждает Haiku, потому что умеет работать не только с приложениями, но и с системными программами.

Удаление пакета из GUI

Легко! На Mac, нужно перетянуть иконку приложения в корзину, и на этом все.

Обычно искать надо в /Haiku/system/packages (при общесистемной установке по-умолчанию), или в /Haiku/home/config/packages (я уже говорил, что "config" — неправильное название?). На Haiku, во-первых, нужно найти, где находится пакет в системе, потому что вы редко когда установите его куда надо (все делает система). Впрочем, я бы так не сказал. Потом приложение просто перетягивается в корзину, и на этом все.
Легко! Вот что происходит на самом деле:


Вот что получается, если перетянуть приложение в корзину из /Haiku/system/packages

Я не пытался переместить системный каталог, а поскольку все пакеты устанавливаются в системный каталог — невозможно удалить пакет .hpkg без изменения "его содержимого". Просто попробовал переместить в корзину свое вчерашнее приложение "Привет, мир" на QtQuickApp. Обычный пользователь испугался бы, нажал бы кнопку "Отмена", назначенную по-умолчанию.

waddlesplash: Поясняет mr.

Скорее всего нам надо настроить его так, чтобы предупреждение вылезало только при перемещении самого пакета. Этому сообщению уже более 10 лет. Обычным пользователям в любом случае не нужно так делать.

Щелкаю дважды по пакету в /Haiku/system/packages, ожидая, что покажется кнопка "Uninstall". Хорошо, возможно, надо сделать это, используя HaikuDepot? «Uninstall», где ты? Не-а, есть (только) «Install».

Получается так: Для прикола попробовал посмотреть, что случится, если я нажму "Install" для уже установленного пакета.


Это получается, если вы пробуете установить уже установленный пакет.

Следом появляется:


Если нажать "Apply changes" в предыдущем окне — получится так

[автор ссылку не предоставил, — прим. Предполагаю, что это программная ошибка, ссылка на заявку уже есть. переводчика]

Быстрое решение: Добавить кнопку "Uninstall", если пакет уже есть в /Haiku/system/packages, или в /Haiku/home/config/packages.

При просмотре списка пакетов, установленных в HaikuDepot, я вижу свой пакет в списке и могу его удалить.

Но я могу представить, что при должной настройке пользовательский опыт на Haiku будет лучше, чем на Mac. В этой категории побеждает Mac. (Один из разработчиков оценил это так: "Меньше часа для добавления указанного функционала в HaikuDepot, если вы немного знаете С++", есть добровольцы?)

Удаление чего-либо из пакета

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

Обычно образы .dmg накапливаются в каталоге загрузок, пакеты же копируются пользователем в /Applications. На Mac, пользователь на самом деле обычно работает с файлом .dmg, откуда берется пакет приложения .app. (Одна из вещей, которая мне не нравится на Mac. Есть мнение, что многие пользователи сами не знают, что они делают, эта гипотеза подтверждается бывшим сотрудником Apple. Перетянули иконку в корзину = вот и все. А, к примеру, с AppImage нет разницы между приложением и пакетом, в котором оно было. Легко!)

А вот что происходит, если перетянуть приложение из apps/ в корзину: На Haiku, также есть разделение между apps/ и packages/, так что я сомневаюсь, что пользователям от этого стало понятнее.


Вот что получается при попытке удаления приложения, взятого из файла .hpkg

Технически оно правильно (ведь приложение размещено на файловой системе только для чтения, в первую очередь), но это не особо полезно пользователю.

Быстрое решение: вместо этого предложить через GUI удалить .hpkg

Получил сообщение "Невозможно переместить или копировать объекты на томе только для чтения". Для прикола я попробовал дублировать приложение, нажав Alt+D. К сожалению, вывод команды mount не проясняет ситуацию (как и было сказано в одной из предыдущих статей), mountvolume не показывает искомое (по всей видимости монтируемые через loop пакеты .hpkg не считаются "томами"), а также я забыл альтернативные команды. А все потому, что /system (помимо /system/packages и /system/settings) является точкой монтирования packagefs (помните, как она появляется в выводе df?).

Однако можно представить, что после подстройки, пользовательский опыт на Haiku будет лучше, чем на Mac. В этой категории никто не победил, кроме AppImage (но это, если совсем честно, предвзятое мнение).

Вероятно, это сродни отношению "папки" к «каталогу": большинство каталогов отображаются в файловом менеджере в виде папок, но не все из них (к примеру, пакеты, обрабатываемые как файлы). Примечание: надо выяснить, что такое "том" по отношению в «разделу». Подобные выкладки делают меня нердом официально?

Копирование содержимого пакета на другую систему

На Mac, тупо перетягиваю пакет .app, а поскольку зависимости внутри пакета — они перемещаются вместе.

На Haiku, перетягиваю приложение, но зависимости не обрабатываются вообще.

Быстрое решение: Пусть вместо этого предлагается перетянуть пакет ```.hpkg целиком, вместе с зависимостями, при их наличии.

По крайней мере для меня, любителя их парадигмы. В этой категории однозначно побеждает Mac. На Haiku надо бы скопировать .hpkg вместо приложения, но система не предлагает мне такого...

Скачивание пакета со всеми его зависимостями

Напротив, некоторые машины (да, я смотрю на вас, современные Windows, Mac и Linux) забывают об этом. Не каждая машина подключена к сети все время. переводчика]. Для меня важно, что я могу пойти к примеру в Интернет-кафе, накачать софта на съемный носитель, вставить этот носитель в домашний компьютер и быть уверенным, что все сработает [рисковый парень, проворачивать такое на Windows… — прим.

В результате чуть чаще, чем всегда, я обычно получаю неудовлетворенные зависимости на Windows и Linux.

Чаще всего у него нету зависимостей, кроме тех, что предоставляются самой MacOS по-умолчанию. На Mac это обычно один файл, все что нужно — скачать .dmg. В качестве исключения можно привести сложные приложения, требующие соответствующей среды выполнения, к примеру java.

Есть ли способ скачать все зависимости для данного пакета .hpkg, кроме тех, которые устанавливаются в Haiku по-умолчанию и, следовательно, должны быть в каждой системе Haiku? На Haiku скачать пакет .hpkg для, скажем, того же приложения на java, может оказаться недостаточным, поскольку java может как присутствовать, так и отсутствовать на целевой машине.

В этой категории с небольшим отрывом побеждает Mac.

waddlesplash: Комментирует mr.

Добавить поддержку для этого не так уж и сложно, если в этом есть реальная нужда. Для того, чтобы написать программу для сбора всех зависимостей приложения в виде набора пакетов .hpkg для кого-нибудь, знакомого с внутренним устройством Haiku, достаточно порядка 15 минут. Но для меня это редкая ситуация.

Задержим дыхание до следующей статьи в этом цикле.

Перемещение пакетов в обособленное место

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

Я все еще могу двойным щелчком открыть приложение как обычно я это делал с загрузочного тома. На Mac я просто перемещаю пакеты .app на съемный диск или сетевой каталог в Finder, и на этом все. Просто!

Я не знаю, как это сделать, используя только GUI. На Haiku, как мне сказали, этого можно достичь путем перемещения моих .hpkg пакетов на съемный диск или сетевой каталог, но потом надо воспользоваться некоторыми недокументированными командами в консоли для того, чтобы смонтировать их в систему.

В этой категории побеждает Mac.

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

Если же будет спрос больше, чем у одного пользователя, мы реализуем это. Тут оптимизация из расчета обычного применения. В любом случае есть возможность сторонней реализации.

Об этом расскажем в следующей статье.

Конечно же, у разработчиков есть возможность отказа через app_flags. Если говорить о сетевых каталогах: было бы замечательно (предполагаю LAN вечеринки) иметь простые, обнаруживаемые, общесетевые приложения (например, по Zeroconf), которые можно скопировать на локальный компьютер или запустить сразу из локальной сети.

Итоговый отчет по интеграции системы hpkg c GUI

Во всяком случае, есть несколько вещей, которые можно улучшить по части UX... Я думаю, что прежде всего из-за относительной новизны интеграция .hpkg с GUI все еще оставляет желать лучшего.

Еще одна вещь: Kernel Debug Land

Ну, на Haiku это возможно благодаря Kernel Debug Land. Было бы шикарно при kernel panic иметь возможность вводить команды, к примеру syslog | grep usb. Легко, нажав Alt+PrintScn+D (мнемоника Debug). Как же увидеть эту магию в действии, если у вас все работает как надо без попадания в kernel panic? Мне сразу вспоминаются Programmer’s Key, позволявшая изначальным разработчикам Macintosh входить в отладчик (если он был установлен, разумеется).

Заключение

Я начинаю понимать, что утонченность системы Haiku происходит из того, что работа ведется одной небольшой командой с четкой ориентацией на рабочее окружение при доступности всех слоев системы.
Резкий контраст с миром Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, где все разбито на мелкие кусочки до такой степени, что абстракция сидит на абстракции и костылями погоняет.
Также пришло понимание того, как система .hpkg комбинирует лучшие практики традиционных пакетных менеджеров, Snappy, Flatpak, AppImage, даже btrfs, и смешивает их с принципом "просто работает" от Mac.

Но это не я, а красота и простота системы. Словно что-то "переключилось" в голове, и я понял, как система .hpkg умеет откатываться, — просто взглянув на нее. Многое здесь пропитано духом изначального Mac.

Ведь эти вещи можно исправить и они рано или поздно появятся. Да, просмотр страниц в браузере может быть дерганым и работать, как улитка, приложений может не хватать (нет Gtk, Electron — разработчики сделали выводы, что они плохо сочетаются с утонченностью), ускорение видео и 3d может вообще отсутствовать, но все же мне нравится эта система. Это только вопрос времени и, возможно, чутка красных глаз.

Я не могу предложить помощь, но думаю с этого момента начнется год Haiku на рабочем столе.

Случайные проблемы

Может уже есть заявки, или я должен открыть их?

  • BeScreenCapture должен иметь возможность экспорта в GIF, как в Peek. Это можно сделать с помощью ffmpeg, уже имеющимся для Haiku. Заявка.
  • Программа для создания снимков экрана не может сделать снимок модального окна, вместо этого снимая целый экран
  • Нельзя обрезать снимки экрана с помощью инструмента обрезки в WonderBrush, а после — сохранить результат в файл
  • Мне не особенно нравится курсор в виде руки в Haiku, но я думаю, что это связано с теплыми ностальгическими чувствами. Это особенно раздражает при использовании инструмента обрезки в Krita, поскольку получается неточная обрезка (см. снимки экрана с модальными диалогами в этой статье). Курсор в виде перекрестия был бы чудесен. Заявка.

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

Приглашаем вас в русскоязычный telegram-канал. Появились вопросы?

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

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

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

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

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

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

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

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