🥇Мій шостий день з Haiku: під капотом ресурсів, іконок та пакетів

TL, д-р: Haiku - операційна система, спеціально розроблена для ПК, тому у неї є кілька хитрощів, що роблять її робоче оточення набагато краще за інших. Але як воно працює?

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

Ресурси у файлах ELF

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

Ресурси? Цитата від Брюса Хорна, початкового автора програми Macintosh Finder та «батька» Macintosh Resource Manager:

Мене непокоїть жорсткий характер традиційного написання коду. Для мене сама ідея програми, замороженої в коді, без можливості змінити будь-що динамічно - дика дикість. Повинна бути можливість змінювати якнайбільше на етапі виконання. Зрозуміло, сам код програми не може бути змінений, але щось можна поміняти і без перекомпіляції коду?

На оригінальному Macintosh зробили так, що ці файли мають «секцію даних» і «секцію ресурсів», що надзвичайно полегшило збереження різних речей, наприклад іконок, перекладів тощо. у виконуваних файлах.

На Maс для цього застосовується Відредагувати, графічна програма для – раптово – редагування ресурсів.

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?
Згідно з документації:

Для перегляду ресурсів, що постачаються в пакеті програми, можна перетягнути файл, що виконується, на програму типу Ресурс. Також можна зайти в термінал та запустити команду 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.

Список статей: перша Друга третя четверта п'ята

Джерело: habr.com

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