🥇Мой шестой день с 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.

Ресурси, като иконите, файлове на потребителския интерфейс и други, се съхраняват в пакета под формата на файлове. Концепцията всъщност се връща обратно към корените в 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.1За да компилирате rdef скрипт в ресурсен файл:
    rc [options] [-o ] ...За да конвертирате ресурсен файл обратно в rdef скрипт:
    rc [options] [-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, очаквайки да се появи бутон „Деинсталиране“. Не, има (само) „Инсталирай“. „Деинсталиране“, къде си?

За шега опитах да видя какво ще се случи, ако натисна „Инсталирай“ за вече инсталиран пакет. Става така:

Така се получава, ако опитате да инсталирате вече инсталиран пакет.

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

Ако натиснете „Приложи промените“ в предишния прозорец — става така

Предполагам, че това е софтуерна грешка, връзка към заявка вече има. [авторът не е предоставил връзка, — бел. преводача]

Бързо решение: Добавете бутон „Деинсталиране“, ако пакетът вече е в /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.

Бележка: трябва да разберем какво е „том“ по отношение на „раздел“, може би е подобно на отношението „папка“ към „каталог“: повечето каталози се показват в файловия мениджър като папки, но не всички от тях (например, пакетите, обработвани като файлове). Подобни изказвания правят ли ме офицално nerd?

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

На 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

Имате ли въпроси? Присъединете се към нашия руски telegram-канал.

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

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

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

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