Моят шести ден с Haiku: под капака на ресурсите, иконите и пакетите

TL;DR: Haiku — операционна система, специално разработена за РС, затова има няколко трика, които правят работната й среда много по-добра от другите. Но как точно работи тя?

Наскоро открих Haiku, изненадващо добра система. Все още съм впечатлен от това колко гладко работи, особено в сравнение с работните среди на Linux. Днес ще надникна под капака. Там, където е нужно за по-дълбочинно разбиране, ще направя сравнение с оригиналния Macintosh, Mac OS X и работните среди на Linux (стандарт XDG от freedesktop.org).

Ресурси в ELF файлове

Вчера научих, че IconOMatic може да запазва иконки в ресурсите rdef в изпълними ELF файлове. Днес искам да видя как всъщност работи.

Ресурси? Цитат от Брюс Хорн, оригиналният автор на програмата Macintosh Finder и „бащата“ на Macintosh Resource Manager:

Мен ме притеснява строгият характер на традиционното писане на код. За мен самата идея за приложение, замразено в код, без възможност за динамични промени — е дълбока абсурдност. Трябва да има възможност да се променя колкото се може повече по време на изпълнение. Разбира се, самият код на приложението не може да бъде променен, но не може ли нещо да бъде променено и без повторна компилация на кода?

На оригиналния Macintosh беше направено така, че тези файлове имат „секция данни“ и „секция ресурси“, което изключително улесни съхранението на различни елементи, например иконки, преводи и т.н. в изпълними файлове.

На Mac за това се използва 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 1.1
За да компилирате rdef скрипт в ресурсен файл:
    rc [опции] [-o ] ...
За да конвертирате ресурсен файл обратно в rdef скрипт:
    rc [опции] [-o ] -d ...
Опции:
    -d --decompile       създайте rdef скрипт от ресурсен файл
       --auto-names      конструирайте имена на ресурси от ID символи
    -h --help            покаже това съобщение
    -I --include    добавете  в списъка на включващите пътища
    -m --merge           не изтривайте съществуващото съдържание на изходния файл
    -o --output          посочете име на изходен файл, по подразбиране е out.xxx
    -q --quiet           не показвайте никакви съобщения за грешки
    -V --version         покажи версията на софтуера и лиценза

Можете да използвате програмата 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

Гледайки на такова нещо, вече можете да почувствате, какво представлява този фрагмент.

Разбира се, има скалируеми, които съдържат, както можете да разберете, векторни икони. Защо тогава има нещо още? Защото резултатът от рендерирането на векторна графика в малки размери може да е по-лош от идеалния. Искаме да имаме различни варианти, оптимизирани за различни размери. В работни среди 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] активен пакет: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] активен пакет: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] активен пакет: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] активен пакет: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] активен пакет: "llvm_libs-5.0.0-3-x86_64.hpkg"

Страхотно, нали? Дръжте се, по-нататък става още по-интересно!

Има един много специален пакет:

KERN: package_daemon [16040020:   924] активен пакет: "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, ако знаете малко C++", има доброволци?)

Изтриване на нещо от пакета

Нека опитаме да изтрием самото приложение, а не пакета .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.

Според г-н waddlesplash:

Тук оптимизацията е изчислена за обичайнното приложение. Ако обаче има повече търсене от един потребител, ще го реализираме. Във всеки случай е възможно външно реализиране.

Ще поговорим за това в следващата статия.

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

Финален отчет за интеграция на системата hpkg с 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

Имате въпроси? Каним ви в рускоезичния телеграм канал.

Преглед на грешките: Как да си простреляте крака в C и C++. Сборник рецепти на Haiku OS

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

Списък на статиите: Първа Втора Трети Четвърта Пета

Източник: habr.com