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

Недавно я открыл для себя Haiku, неожиданно хорошую систему. До сих пор поражен тем, как гладко она работает, особенно по сравнению с рабочими окружениями на Linux. Сегодня я загляну под капот. Там, где это будет нужно для углубленного понимания, я проведу сравнение с оригинальным 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.

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

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

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

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

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

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

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

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

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

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

Как же управлять ресурсами в файлах ELF? Используя rsrc и rdef. rdef файлы собираются в rsrc. Файл rdef хранится в обычном текстовом формате, так что работать с ним гораздо легче. Файл в формате 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. Таким образом, нельзя утонченно обработать ситуацию с присутствием нескольких версий приложения в системе.

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

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. Умопомрачительное решение, без исключений. Согласно документации:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С помощью 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 пакетов

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

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

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

Вернемся к 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, — прим. переводчика]. Затем представьте, сколько времени потребуется для того, чтобы этот подход был внедрен в дистрибутивы. Говорят же: возьми простую задачу, раздели между разными исполнителями, и она так усложнится, что ее будет уже не решить. Haiku в данном случае открыла мне глаза. Думаю, именно это и происходит на Linux сейчас (Linux в данном случае — собирательный термин, обозначающий стек Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Было бы шикарно при kernel panic иметь возможность вводить команды, к примеру syslog | grep usb. Ну, на Haiku это возможно благодаря Kernel Debug Land. Как же увидеть эту магию в действии, если у вас все работает как надо без попадания в kernel panic? Легко, нажав Alt+PrintScn+D (мнемоника Debug). Мне сразу вспоминаются 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-канал.

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

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

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