🥇Моят шести ден с 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 на оригиналния 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.

Какво се случва с Хайку сега? По принцип горе-долу същото.

На теория би било възможно да поставите ресурси в желания раздел на 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 нямаше векторни икони, повечето приложения вместо това имаха две растерни икони в своите изпълними файлове).

Разбира се, можете да добавите ресурси с всякакви желани идентификатори и типове и след това да ги прочетете в самото приложение или други приложения, използващи класа BResources. Но първо, нека разгледаме увлекателната тема за иконите.

Векторни икони в стил хайку

Разбира се, не само 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, съдържащ всички размери, така че различните версии на едно и също приложение да имат различни икони.
Много по-добре! Иконите пътуват с приложението, всички ресурси са в един файл.

Да се върнем към Хайку. Умопомрачително решение, без изключения. Според документация:

Разработен е специален HVIF формат, силно оптимизиран за малки размери и бързо изобразяване. Следователно нашите икони в по-голямата си част са много по-малки, отколкото в растер или в широко използвания SVG формат.

И те все още са оптимизирани:

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

Разликата е от порядък!

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

Различни нива на детайлност (LOD) в зависимост от размера на рендера

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

Добавяне на икона към приложението

Сега мога да добавя икона към създадения пакет последен път, като се вземе предвид цялата получена информация.
Е, тъй като в момента не съм особено нетърпелив да нарисувам собствена икона за моето QtQuickApp „Hello, World“, го изтеглям от 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, винаги насочват стрелката към мен.

Да се върнем към Хайку. Възможно ли е да се намери оптималният баланс между традиционните пакетни системи и доставката на базиран на изображения софтуер? Нейните пакети .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"

Той съдържа много минималистична операционна система, включително ядрото. Вярвате или не, дори самото ядро не се премахва от boot тома (root дял), а внимателно се зарежда на мястото си от пакета .hpkg. Еха! Вече споменах, че мисля, че част от цялостната сложност и последователност на Haiku идва от факта, че цялата система, от ядрото и основното потребителско пространство до управлението на пакети и инфраструктурата за изпълнение, е разработена съвместно от един екип. Представете си колко различни групи и екипи ще са необходими, за да управляват нещо подобно на Linux [Представям си проекта PuppyLinux - прибл. преводач]. Тогава си представете колко време ще отнеме този подход да бъде възприет в дистрибуции. Казват: вземете прост проблем, разделете го между различни изпълнители и той ще стане толкова сложен, че вече няма да е възможно да го решите. Хайку в този случай ми отвори очите. Мисля, че точно това се случва в 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-<...>/ съдържа само текстов файл със списък на активните пакети в това състояние (в случай на инсталиране на пакети без премахване), а ако пакетите са премахнати или актуализирани - директорията на състоянието съдържа стари версии на пакети.

Когато системата се стартира, въз основа на списъка с пакети се взема решение за активиране (монтиране) на пакети. Толкова е просто! Ако нещо се обърка по време на изтеглянето, можете да кажете на мениджъра за изтегляне да използва различен, по-стар списък. Проблема решен!

Програма за изтегляне на хайку. Всяка входна точка показва съответното „активно състояние“

Харесвам подхода да имам прости текстови файлове като списък с „активно състояние“ с имена, които са лесни за разбиране .hpkg. Това е в рязък контраст с това да бъдеш създаден за машини, а не за хора. на куп от OSTree или Flatpak във файловата система (на същото ниво като Microsoft GUID).

Списък на активните пакети за всеки момент от време

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

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

GUI интеграция за .hpkg система

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

Следните сценарии идват на ум:

Искам да видя съдържанието на пакет .hpkg
Искам да инсталирам пакет
Искам да махна пакета
Искам да премахна нещо, което е влязло в системата като част от пакет
Искам да копирам нещо, което е влязло в системата като част от пакет
Искам да изтегля всички зависимости на пакет, който може да не е част от всяка инсталация на Haiku (например имам физически изолирана машина без достъп до интернет.)
Искам да преместя моите пакети (или част от тях) отделно на друго място, отделно от тома за зареждане (главния дял) (защото например нямам достатъчно място в него).

Това трябва да обхваща повечето от основните случаи от моята ежедневна работа. Е, да започваме.

Проверка на съдържанието на пакета

На Mac Просто щраквам с десния бутон върху пакета, за да го отворя и да видя съдържанието във Finder. В края на краищата, в действителност това е просто прикрита директория! (Знам, че има пакети .pkg за част от системата, която не е приложения, но обикновените потребители най-често не взаимодействат с тях).

На хайку Щраквам с десния бутон върху пакета, след което щраквам върху „Съдържание“, за да видя какво има вътре. Но тук има само списък с файлове без възможност за отваряне чрез двукратно щракване.
Би било много по-добре, ако имаше начин за (временно) монтиране на пакета .hpkg да се разглеждат чрез файлов мениджър и потребителят няма да трябва да се тревожи за подробности за внедряването. (Между другото, можете да отворите .hpkg пакет в Expander, който може да го разопакова като всеки друг архив).

Интерфейсът на HaikuDepot ви позволява да видите списък с пакетни файлове, но няма начин да видите съдържанието, като например щракнете двукратно върху README.md

Mac печели в тази категория, но добавянето на функционалността на HaikuDepot, която искате, не би трябвало да е твърде трудно.

Инсталиране на пакет чрез GUI

На Mac, повечето дискови изображения .dmg съдържат пакети .app. Щракнете двукратно върху изображението на диска и след това копирайте пакета, например като го плъзнете в /Applications във Finder. За мен това се разбира от само себе си, но съм чувал, че някои начинаещи може да не са в състояние да се справят с това. По подразбиране Apple "предлага" директория за цялата система /Applications (при NeXT беше както мрежово, така и индивидуално), но можете лесно да поставите приложенията си на файлов сървър или в поддиректория $HOME/Applications, ако ти харесва така.

На хайку, щракнете два пъти върху пакета, след това щракнете върху „Инсталиране“, не може да бъде по-лесно. Чудя се какво се случва, ако даден пакет има зависимости, които са налични в HaikuPorts, но все още не са инсталирани. В Linux те наистина не знаят какво да правят в тази ситуация, но решението е очевидно - попитайте потребителя дали трябва да изтегли и инсталира зависимости. Точно това, което прави Хайку.

Изтеглих пакета „sanity“ ръчно и щракнах върху него, мениджърът на пакети знае откъде да вземе своите зависимости (ако приемем, че хранилищата вече са регистрирани в системата). Не всяка Linux дистрибуция може да направи това.

Друг начин е да използвате файлов мениджър, просто плъзнете и пуснете .hpkg пакет или ин /Haiku/system/packages (за инсталация в цялата система, по подразбиране) или в /Haiku/home/config/packages (за индивидуална инсталация; не се предлага при двойно щракване - все още ме дразни думата "config" на това място, което за мен в случая е синоним на "settings"). И концепцията за множество потребители дори все още не е достъпна за Haiku (това вероятно е причината да е толкова проста - не знам, може би възможностите за много потребители ще усложнят ненужно нещата за десктоп среда).

Haiku печели в тази категория, защото може да работи не само с приложения, но и със системни програми.

Премахване на пакет от GUI

На Mac, трябва да плъзнете иконата на приложението в кошчето и това е всичко. Лесно!

На хайку, първо, трябва да намерите къде се намира пакетът в системата, защото рядко го инсталирате на правилното място (системата прави всичко). Обикновено трябва да погледнете /Haiku/system/packages (с инсталация по подразбиране за цялата система) или в /Haiku/home/config/packages (Споменах ли, че „config“ е погрешно название?). След това приложението просто се изтегля в кошчето и това е всичко.
Лесно! Това обаче не бих казал. Ето какво наистина се случва:

Това се случва, ако плъзнете приложение в кошчето от /Haiku/system/packages

Току-що се опитах да преместя вчерашното си приложение „Hello World“ на QtQuickApp в кошчето. Не се опитах да преместя системната директория, и тъй като всички пакети са инсталирани в системната директория, е невъзможно да премахнете пакета .hpkg без промяна "съдържанието му". Един обикновен потребител би се уплашил и би натиснал бутона „Отказ“, зададен по подразбиране.

Обяснява г-н. 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 няма разлика между приложението и пакета, в който е било. Плъзнете иконата в кошчето = това е. Лесно!)

На хайку, също има разделение между apps/ и packages/, така че се съмнявам, че това е направило нещо по-ясно за потребителите. Но какво се случва, ако плъзнете приложение от apps/ Добави в кошницата:

Това се случва, когато се опитате да премахнете приложение, взето от файл .hpkg

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

Бързо решение: предложете вместо това да използвате GUI за изтриване .hpkg

Просто за забавление се опитах да дублирам приложението, като натиснах Alt+D. Получих съобщението „Не мога да преместя или копирам обекти на том само за четене“. И всичко това, защото /system (Освен това /system/packages и /system/settings) е точката на монтиране на packagefs (запомнете как се появява в изхода df?). За съжаление резултатът от командата mount не изяснява ситуацията (както беше казано в една от предишните статии), mountvolume не показва това, което търсите (очевидно пакети, монтирани чрез цикъл .hpkg не се считат за "томове"), а също така забравих алтернативните команди.

Никой не спечели в тази категория освен AppImage (но това, за да бъда напълно честен, е пристрастно мнение). Човек обаче може да си представи, че след настройка потребителското изживяване на Haiku ще бъде по-добро, отколкото на Mac.

Забележка: трябва да разберете какво е „том“ във връзка с „раздел“. Това вероятно е подобно на връзката между "папка" и "директория": повечето директории се показват като папки във файловия мениджър, но не всички от тях (пакети, третирани като файлове, например). Този вид дисплей прави ли ме официален маниак?

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

На Mac, глупаво влача пакета .app, и тъй като зависимостите са вътре в пакета, те се движат заедно.

На хайку, влача приложението, но зависимостите изобщо не се обработват.

Бързо решение: Нека вместо това предложим да изтеглите целия пакет `.hpkg, заедно с всички зависимости, ако има такива.

Mac очевидно печели в тази категория. Поне за мен, любителя на тяхната парадигма. Трябва да го копирам в Хайку .hpkg вместо приложение, но системата не ми предлага това...

Изтеглете пакет с всичките му зависимости

Не всяка машина е свързана към мрежата през цялото време. Напротив, някои машини (да, гледам ви, модерни Windows, Mac и Linux) забравят за това. За мен е важно да мога да отида например в интернет кафе, да изтегля софтуер на преносимо устройство, да поставя това устройство в домашния си компютър и да съм сигурен, че всичко ще работи [рискован човек, правя това на Windows... - прибл. преводач].

В резултат на това имам склонност да се озовавам с неудовлетворени зависимости от Windows и Linux малко по-често от обикновено.

На Mac това обикновено е един файл, всичко, което трябва да направите, е да изтеглите .dmg. Най-често той няма зависимости, различни от тези, предоставени от самия MacOS по подразбиране. Изключение са сложните приложения, които изискват подходяща среда за изпълнение, например java.

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

Mac печели тази категория с малка разлика.

Коментари Mr. waddlesplash:

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

Нека затаим дъх до следващата статия от тази поредица.

Преместване на пакети на отделно място

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

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

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

Mac печели в тази категория.

Според г-н. waddlesplash:

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

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

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

Окончателен доклад за интегрирането на системата hpkg с GUI

Мисля, че основно поради относителната новост на интеграцията .hpkg GUI все още оставя много да се желае. Както и да е, има няколко неща, които могат да бъдат подобрени по отношение на UX...

Още нещо: Kernel Debug Land

Би било чудесно да можете да въвеждате команди по време на паника на ядрото, например syslog | grep usb. Е, на Haiku това е възможно благодарение на Kernel Debug Land. Как можете да видите тази магия в действие, ако всичко работи както трябва, без да изпадате в паника на ядрото? Лесно чрез натискане на Alt+PrintScn+D (мнемоника за отстраняване на грешки). Веднага се сещам Ключ на програмиста, което позволи на оригиналните разработчици на Macintosh да влязат в програмата за отстраняване на грешки (ако има инсталиран такъв, разбира се).

Заключение

Започвам да разбирам, че сложността на системата Haiku идва от факта, че работата се извършва от един малък екип с ясен фокус върху работната среда, като всички слоеве на системата са достъпни.
Рязък контраст със света на Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, където всичко е разбито на малки парчета до такава степен, че абстракцията седи върху абстракцията и се кара с патерици.
Имаше и разбиране за това как системата .hpkg съчетава най-добрите практики на традиционните мениджъри на пакети, Snappy, Flatpak, AppImage, дори btrfs, и ги смесва с подхода „просто работи“ на Mac.

Сякаш нещо се „превключи“ в главата ми и разбрах как работи системата .hpkg знае как да се претърколи, само като я погледне. Но не съм аз, а красотата и простотата на системата. Голяма част от това е вдъхновено от духа на оригиналния Mac.

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

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

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

Може би вече има заявки или трябва да ги отворя?

BeScreenCapture трябва да може да експортира в GIF като Peek. Това може да се направи с помощта на ffmpeg, който вече е наличен за Haiku. Приложение.
Софтуерът за екранни снимки не успява да заснеме модален прозорец, вместо това заснема целия екран
Не можете да изрязвате екранни снимки с помощта на инструмента за изрязване на WonderBrush и след това да запазвате резултата във файл
Не харесвам особено ръчния курсор в Хайку, но мисля, че е свързан с топлото носталгично чувство. Това е особено досадно, когато използвате инструмента за изрязване в Krita, тъй като води до неточно изрязване (вижте екранни снимки на модални диалогови прозорци в тази статия). Курсор с мерник би бил чудесен. Приложение.

Опитайте сами! В края на краищата проектът Haiku предоставя изображения за зареждане от DVD или USB, генерирани ежедневно. За да инсталирате, просто изтеглете изображението и го запишете на флаш устройство, като използвате офорист

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

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

От автор превод: това е шестата статия от поредицата за Хайку.

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

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

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