TL, д-р: Haiku - аперацыйная сістэма, спецыяльна распрацаваная для ПК, таму ў яе ёсць некалькі хітрасцяў, якія робяць яе працоўнае асяроддзе нашмат лепш за іншых. Але як яно працуе?
я адкрыў для сябе Haiku, нечакана добрую сістэму. Да гэтага часу здзіўлены тым, як гладка яна працуе, асабліва ў параўнанні з працоўнымі асяродкамі на Linux. Сёння я зазірну пад капот. Там, дзе гэта будзе трэба для паглыбленага разумення, я правяду параўнанне з арыгінальным Macintosh, Mac OS X і працоўнымі асяроддзямі Linux (стандарт XDG ад freedesktop.org).
Рэсурсы ў файлах ELF
Учора я пазнаў, што IconOMatic умее захоўваць абразкі ў рэсурсах rdef у выкананых файлах ELF. Сёння хачу паглядзець, як яно працуе насамрэч.
Рэсурсы? ад , першапачатковага аўтара праграмы Macintosh Finder і "бацькі" Macintosh Resource Manager:
Мяне непакоіць жорсткі характар традыцыйнага напісання кода. Для мяне сама ідэя прыкладання, замарожанага ў кодзе, без магчымасці змяніць штосьці дынамічна - найдзікая дзікасць. Павінна быць магчымасць змяняць як мага больш на этапе часу. Зразумела, сам код прыкладання не можа быць зменены, але ж нешта можна памяняць і без перакампілявання кода?
На арыгінальным Macintosh зрабілі так, што ў гэтых файлаў ёсць "секцыя дадзеных" і "секцыя рэсурсаў", што незвычайна палегчыла захаванне розных рэчаў, напрыклад абразкоў, перакладаў і да т.п. у выкананых файлах.
На Maс для гэтага ўжываецца , графічная праграма для - раптоўна - рэдагавання рэсурсаў.
ResEdit на арыгінальным Macintosh
У выніку з'явілася магчымасць рэдагаваць абразкі, пункты меню, пераклады і інш. досыць лёгка, аднак яны ўсё роўна "падарожнічаюць" з прыкладаннямі.
У любым выпадку гэты падыход меў вялікі недахоп: працаваў толькі на файлавых сістэмах Apple, што стала адной з прычын чаму Apple адмовілася ад "секцыі рэсурсаў" пры пераходзе на Mac OS X.
На Mac OS X Apple жадалі рашэнні, незалежнага ад файлавай сістэмы, таму ўжылі канцэпцыю пакетаў (з NeXT), каталогаў, якія апрацоўваюцца файлавым мэнэджарам як "непразрыстыя аб'екты", падобна файлам, а не каталогам. Любы пакет з дадаткам у фармаце .app мае, сярод іншага, файл Info.plist (у нейкім аналогу JSON ці YAML ад Apple), які змяшчае метададзеныя прыкладанні.
Ключы файла Info.plist з пакета прыкладання Mac OS X.
Рэсурсы, напрыклад абразкі, файлы UI і іншыя, захоўваюцца ў пакеце ў выглядзе файлаў. Канцэпцыя фактычна вярнулася зваротна да вытокаў у NeXT.
Mathematica.app на NeXTSTEP 1.0 у 1989 годзе: адлюстроўваецца як каталог з файламі ў тэрмінале, але як адзіны аб'ект у графічным файлавым мэнэджэры.
Вернемся да BeOS, на канцэпцыях якой заснавана Haiku. Яе распрацоўшчыкі пры пераходзе з PEF (PowerPC) на ELF (x86) (той жа, што прымяняецца на Linux) вырашылі дадаць секцыю рэсурсаў у канец файлаў ELF. Для гэтага не выкарыстоўвалася ўласная належная секцыя ELF, яе проста дапісвалі ў канец файла ELF. У выніку праграмы strip і іншыя з binutils, не дасведчаныя аб такім, проста абразалі яе. Таму, дадаўшы рэсурсы ў файл ELF на BeOS, лепш не працаваць з ім прыладамі Linux.
А што ж адбываецца зараз з Haiku? У прынцыпе, больш-менш тое самае.
У тэорыі можна было б размяшчаць рэсурсы ў патрэбнай секцыі ELF. Згодна з распрацоўшчыкам на канале #haiku у сетцы irc.freenode.net:
З ELF секцыя мела б больш сэнсу… адзіная прычына, па якой мы так не робім, — так рабілі ў BeOS»
І змяняць гэта зараз не варта.
Кіраванне рэсурсамі
Рэсурсы пішуцца ў структураваным "рэсурсным" фармаце: па сутнасці гэта спіс рэсурсаў з памерамі і потым ужо іх змесціва. Успомніўся .
Як жа праверыць рэсурсы ў 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, выкарыстаючы функцыю ). Прыкладанні зB_EXCLUSIVE_LAUNCHпаведамляюцца, калі карыстач спрабуе запускаць іх паўторна: да прыкладу, атрымліваюць шлях файла, які карыстач жадае адкрыць з іх дапамогай.vector_icon: Вектарны абразок прыкладання (У BeOS не было вектарных абразкоў, большасць прыкладанняў замест іх мела па двух растравых абразкоў у выкананых файлах).
Вядома ж, можна дадаць рэсурсы з любымі жаданымі ID і тыпамі, пасля чаго чытаць іх у самім дадатку ці іншых прыкладаннях з дапамогай класа BResources. Але для пачатку давайце спынімся на займальнай тэме абразкоў.
Вектарныя абразкі ў стылі Haiku
Зразумела не толькі Haiku абраў лепшы фармат абразкоў, у гэтай частцы сітуацыя з працоўнымі асяродкамі Linux далёкая ад ідэальнай:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cacheГледзячы на такое ўжо можна адчуць, чаго гэта кавалак.
Вядома, ёсць scalable, які змяшчае, як можна зразумець, вектарныя абразкі. Чаму ж тады ёсць нешта яшчэ? Таму што вынік адмалёўкі вектарнай графікі ў малых памерах можа быць горшым за ідэальны. Жадаецца мець розныя варыянты, аптымізаваныя для розных памераў. У працоўных асяроддзі Linux гэта дасягаецца рассыпаннем па файлавай сістэме абразкоў з рознымі памерамі.
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngЗвярніце ўвагу: няма паняцця розных версій Firefox. Такім чынам, нельга вытанчана апрацаваць сітуацыю з прысутнасцю некалькіх версій дадатку ў сістэме.
Розныя абразкі Firefox у розных версіях. Пакуль што немагчыма апрацаваць гэта ў Linux без розных мыліц.
Mac OS X апрацоўвае крыху больш вытанчана:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsВідаць, што ёсць адзін файл firefox.icns ў пакеце Firefox.app, які змяшчае ўсе памеры, так што розныя версіі аднаго прыкладання маюць розныя абразкі.
Нашмат лепей! Абразкі падарожнічаюць разам з дадаткам, усе рэсурсы ў адным файле.
Вернемся да Haiku. Ашаламляльнае рашэнне, без выключэнняў. Згодна :
Быў распрацаваны адмысловы, высокааптымізаваны для малых памераў і хуткай адмалёўкі, фармат HVIF. Таму нашы абразкі па большай частцы нашмат меншыя чым у растравым ці ў шырокапрымяняльным фармаце SVG.
І яны такі аптымізаваныя:
Памеры абразкі ў HVIF у параўнанні з іншымі фарматамі.
Розніца на парадак!
Але магія тут не заканчваецца. Адзін і той жа HVIF можа паказаць розныя ўзроўні дэталізацыі ў залежнасці ад які адлюстроўваецца памеру, нягледзячы на тое, што гэта вектарны фармат.
Розныя ўзроўні дэталізацыі (LOD) у залежнасці ад памеру адмалёўкі
Зараз аб недахопах: нельга ўзяць SVG, закінуць у ImageMagick і на гэтым скончыць, трэба прайсці некалькі цыклаў для стварэння абразка ў фармаце HVIF. тлумачэнні. Аднак IconOMatic можа дастаткова недасканала імпартаваць SVG; каля 90% дэталяў SVG імпартуецца з некаторай верагоднасцю, астатнія 10% трэба будзе наладзіць і памяняць уручную. Пачытаць больш аб тым, як HVIF робіць сваю магію у блогу
Даданне абразкі ў дадатак
Цяпер я магу дадаць абразок пакету, створанаму , з улікам усёй атрыманай інфармацыі.
Ну а паколькі я цяпер не асабліва гору жаданнем маляваць уласны абразок для майго «Прывітанне, Мір» QtQuickApp – выдзіраю яе з Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorДавайце праверым, што абразок скапіяваны:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONВыглядае добра, аднак чаму, калі новы абразок скапіяваны, ён не адлюстроўваецца?
Скапіяваная VICN:101:BEOS:ICONs пакуль не выкарыстоўваецца ў якасці абразка для прыкладання ў файлавым мэнэджэры
Што ж я прапусціў?
Каментар распрацоўніка:
Трэба стварыць файл
rdefз усімі рэсурсамі, потым выканаць камандуrc имя.rdef, гэта створыць файл.rsrc. Потым трэба выканаць камандуresattr -o имя_бинарника имя.rsrc. Як мінімум, я выкарыстоўваю падобныя каманды для дадання абразкоў да маіх скрыптоў.
Ну, хацелася ж стварыць рэсурс, а не атрыбут. Я проста разгублены.
Разумнае кэшаванне з выкарыстаннем файлавай сістэмы
Адкрыццё і чытанне атрыбутаў ELF працуе марудна. Як я ўжо пісаў вышэй, абразок пішацца ў якасці рэсурсу ў самым файле. Гэты спосаб надзейней, дазваляе перажыць капіраванне на іншую файлавую сістэму. Аднак потым ён таксама капіюецца ў атрыбут файлавай сістэмы, да прыкладу BEOS:ICON. Гэта працуе толькі на вызначаных файлавых сістэмах, напрыклад BFS. Абразкі, якія паказваюцца сістэмай (у Tracker і Deskbar), чытаюцца з гэтага пашыранага атрыбута, таму што падобнае рашэнне працуе хутка. У некаторых месцах (там, дзе хуткасць не важная, да прыкладу тыпавое акно "Пра праграму") сістэма атрымлівае абразок напроста з рэсурсу ў файле. Але гэта яшчэ не канец. Памятаеце, на Mac, карыстачы маглі замяніць абразкі прыкладанняў, каталогаў, дакументаў сваімі, паколькі на Mac ёсць магчымасць зрабіць гэтыя "важныя" рэчы, да прыкладу . На Haiku варта ўспрымаць рэсурс (у файле) у якасці зыходнага абразка, якая пастаўляецца з дадаткам, а атрыбут (у файлавай сістэме BFS) як нешта, якое дазваляе карыстачу ўнесці змены па жаданні (хоць, падказка, графічны інтэрфейс для ўстаўкі карыстацкай абразкі па-над абразкамі па- змаўчанні пакуль яшчэ не рэалізаваны).
Праверка атрыбутаў файлавай сістэмы
З дапамогай resaddr ёсць магчымасць праверыць і ўсталяваць атрыбуты файлавай сістэмы.
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)Па сутнасці гэта "клей", які выконвае пераўтварэнне туды-сюды паміж (надзейнымі) рэсурсамі і (хуткімі) атрыбутамі файлавай сістэмы. А паколькі сістэма мяркуе атрыманне рэсурсаў і выконвае капіраванне аўтаматычна, я не буду далей пра гэта турбавацца.
Чараўніцтва hpkg пакетаў
У наш час (часцей за ўсё) для атрымання праграм на Haiku выкарыстоўваюцца пакеты. .hpkg. Не падманвайцеся простым імем: фармат .hpkg працуе зусім інакш, чым іншыя фарматы са падобнымі імёнамі, з якімі вам даводзілася сутыкацца, у яго ёсць рэальныя суперздольнасці.
З традыцыйнымі фарматамі пакетаў я доўга хваляваўся з-за такога вось факту: спампоўваеш адно (пакет), а ў сістэме ўсталёўваецца іншае (файлы ўсярэдзіне пакета). Досыць цяжка спраўляцца з файламі (напрыклад, выдаліць іх), калі вырабляецца ўсталёўка пакета традыцыйным спосабам. А ўсё таму, што змесціва пакета рассыпаецца па ўсёй файлавай сістэме, уключаючы месцы, куды звычайны карыстач можа не мець доступу на запіс. Гэта ж спараджае цэлы клас праграм. пакетных мэнэджэраў. А бо перанос ужо ўсталяванага ПА, да прыкладу, на іншую машыну, здымная кружэлка або файлавы сервер становіцца нават цяжэй, а то і зусім немагчымым. У звычайнай сістэме на аснове Linux могуць лёгка існаваць ад некалькіх сотняў тысяч да мільёнаў адасобленых файлаў. Само сабой зразумела, гэта адначасова і далікатна, і павольна, напрыклад пры першапачатковай усталёўцы сістэмы, пры ўсталёўцы, абнаўленні і выдаленні звычайных пакетаў, а таксама пры капіяванні загрузнага тома (каранёвай часткі) на іншы носьбіт.
Я працую над праектам AppImage, частковага мыліца для прыкладанняў для канчатковых карыстальнікаў. Гэта фармат распаўсюджвання ПЗ, які збірае прыкладанне і ўсе яго залежнасці ў адну выяву файлавай сістэмы, які мантуецца пры запуску прыкладання. Значна спрашчае рэчы, паколькі той жа ImageMagick раптам ператвараецца ў адзін файл, які кіруецца ў файлавым мэнэджары простымі смяротнымі. Прапанаваны спосаб працуе толькі для ПЗ, як адлюстравана ў імені праекта, а таксама мае ўласны набор балячак, паколькі людзі, якія займаюцца пастаўкамі ПЗ для Linux, заўсёды пераводзяць стрэлкі на мяне.
Вернемся да Haiku. Ці атрымалася знайсці аптымальны баланс паміж традыцыйнымі пакетнымі сістэмамі і пастаўкай ПЗ на аснове вобразаў? Яе пакеты .hpkg фактычна сціснутыя выявы файлавай сістэмы. Пры загрузцы сістэмы ядро мантуе ўсе ўсталяваныя і актыўныя пакеты прыкладна з наступнымі паведамленнямі ядра:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"Стромка, так? Трымайцеся, далей будзе яшчэ страмчэй!
Ёсць вельмі асаблівы пакет:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Ён змяшчае вельмі мінімалістычную аперацыйную сістэму, у тым ліку ядро. Верыце ці не, але нават ядро само па сабе не здабываецца з загрузнага тома (каранёвай часткі), а акуратна загружаецца на сваё месца з пакета .hpkg. Вось гэта да! Я ўжо згадваў аб тым, што, як па мне, частка агульнай вытанчанасці і ўзгодненасці Haiku абумоўленая тым, што ўся сістэма ад ядра і базавай карыстацкай прасторы, а таксама да кіравання пакетамі і інфраструктурай працоўнага асяроддзя распрацоўваецца сумесна адной камандай. Уявіце, колькі розных груп і каманд спатрэбіцца для таго, каб запусціць падобнае на аснове Linux [уяўляю сабе праект PuppyLinux, заўв. перакладчыка]. Затым уявіце, колькі часу спатрэбіцца для таго, каб гэты падыход быў укаранёны ў дыстрыбутывы. Кажуць жа: вазьмі простую задачу, распрані паміж рознымі выканаўцамі, і яна так ускладніцца, што яе будзе ўжо не вырашыць. Haiku у дадзеным выпадку адкрыла мне вочы. Думаю, менавіта гэта і адбываецца на Linux цяпер (Linux у дадзеным выпадку – зборны тэрмін, які пазначае стэк Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Адкат сістэмы з выкарыстаннем hpkg
Як часта атрымліваецца наступная сітуацыя: абнаўленне прайшло паспяхова, а потым высвятляецца, што нешта працуе не так, як трэба? Калі карыстацца звычайнымі пакетнымі мэнэджэрамі, цяжка вярнуць стан сістэмы да моманту часу да ўсталёўкі новых пакетаў (напрыклад, у выпадку, калі нешта пайшло не так). Некаторыя сістэмы прапануюць абыходныя шляхі ў выглядзе злепкаў файлавай сістэмы, але яны досыць грувасткія, а таксама ўжываюцца далёка не ва ўсіх сістэмах. У Haiku гэта вырашана з дапамогай пакетаў .hpkg. Кожны раз, калі мяняюцца пакеты ў сістэме, старыя пакеты не выдаляюцца, а захоўваюцца ў сістэме ў падкаталогах віду /Haiku/system/packages/administrative/state-<...>/ стала. Незавершаныя аперацыі захоўваюць свае дадзеныя ў падкаталогах /Haiku/system/packages/administrative/transaction-<...>/.
змесціва /Haiku/system/packages/administrative. Каталогі "state…" змяшчаюць тэкставыя файлы з імёнамі актыўных пакетаў, "transaction…" — самі пакеты.
"Стары актыўны стан", г.зн. спіс .hpkg пакетаў, актыўных перад зменамі, запісваецца пасля кожнай аперацыі ў файлавым мэнэджэры ў тэкставым файле /Haiku/system/packages/administrative/state-<...>/activated-packages. Падобным чынам пішацца новы "актыўны стан" у тэкставым файле. /Haiku/system/packages/administrative/activated-packages.
Каталог /Haiku/system/packages/administrative/state-<...>/ утрымоўвае толькі тэкставы файл са спісам актыўных пакетаў гэтага стану (у выпадку ўсталёўкі пакетаў без выдалення), а калі пакеты выдаляліся ці абнаўляліся - state каталог утрымоўвае старыя версіі пакетаў.
Пры загрузцы сістэмы на аснове спісу пакетаў прымаецца рашэнне аб актывацыі (мантаванні) пакетаў. Вось дык вось проста! Калі пры загрузцы нешта пойдзе не так - можна паказаць мэнэджару загрузкі выкарыстоўваць іншы, больш стары спіс. Задача вырашана!
Загрузачык Haiku. Кожны пункт уваходу адлюстроўвае адпаведны «актыўны стан»
Мне падабаецца падыход з простымі тэкставымі файламі ў якасці спісу "актыўнага стану", у якіх запісаны зразумелыя для разумення імёны .hpkg. Гэта рэзка кантрастуе з створанай-для-машын-а-не-для-людзей ад OSTree ці Flatpak у файлавай сістэме (па ўзроўні тамака жа, дзе і Microsoft GUID).
Спіс актыўных пакетаў для кожнага моманту часу
Канфігурацыйныя дадзеныя
Мяркуючы па ўсім, у каталогу /Haiku/system/packages/administrative/writable-files змяшчаюцца файлы настроек для пакетаў, але даступныя на запіс. Бо, як падушыце, .hpkg мантуюцца толькі для чытання. Такім чынам, гэтыя файлы павінны быць скапіяваныя з пакетаў перад запісам. Мае сэнс.
Інтэграцыя GUI для сістэмы .hpkg
Давайце зараз паглядзім, як гэтыя бліскучыя пакеты .hpkg спраўляюцца з інтэграцыяй у карыстацкае працоўнае асяроддзе (UX). Бо Haiku прызначаны для персанальнага прымянення, у рэшце рэшт. Асабіста я ўсталяваў высокую планку, параўноўваючы карыстацкі досвед з пакетамі .app на Macintosh з такім жа вопытам на .hpkg. Не буду нават параўноўваць сітуацыю з працоўнымі асяродкамі на Linux, таму што яна абсалютна жудасная ў параўнанні з любымі іншымі.
На розум прыходзяць наступныя сцэнары:
- Я хачу прагледзець змесціва пакета
.hpkg - Я хачу ўсталяваць пакет
- Я хачу выдаліць пакет
- Я хачу выдаліць нешта, якое прыйшло ў сістэму як частка пакета
- Я хачу скапіяваць нешта, што прыйшло ў сістэму як частка пакета
- Я хачу спампаваць усе залежнасці пакета, якія не могуць быць часткай кожнай усталёўкі Haiku (да прыкладу, у мяне ёсць фізічна ізаляваная машына без доступу ў Інтэрнэт.)
- Я жадаю перамясціць мае пакеты (ну, ці іх частка) адасоблена ў іншае месца, асобнае ад загрузнага тома (каранёвай часткі) (таму што, да прыкладу, у мяне недахоп месца на ім).
Гэта павінна ахапіць большасць асноўных выпадкаў маёй паўсядзённай працы. Ну, прыступім.
Праверка змесціва пакета
На Mac я проста пстрыкаю правай кнопкай па пакеце для яго адкрыцця і прагляду змесціва ў Finder. Бо насамрэч гэта проста замаскіраваны каталог! (Я ведаю, што ёсць пакеты .pkg для часткі сістэмы, якая не з'яўляецца праграмамі, але звычайныя карыстальнікі з імі часцей за ўсё і не ўзаемадзейнічаюць).
На Haiku я пстрыкаю правай кнопкай мышы па пакеце, потым пстрыкаю па "Contents" для прагляду таго, што ўсярэдзіне. Але тут проста спіс файлаў без магчымасці адкрыць іх па падвойнай пстрычцы.
Было б значна лепш, калі б меўся спосаб (часовы) мантавання пакета .hpkg для прагляду праз файлавы мэнэджар, а карыстачу не трэба было б клапаціцца аб дэталях рэалізацыі. (Між іншым, можна адкрыць .hpkg пакет у Expander, які можа распакаваць яго як і любы іншы архіў).
У інтэрфейсе HaikuDepot можна прагледзець спіс файлаў пакета, але няма спосабу прагляду змесціва, да прыкладу, двойчы пстрыкнуўшы па README.md
У гэтай катэгорыі Mac перамагае, але даданне патрэбнай функцыянальнасці HaikuDepot не павінна выклікаць вялікіх цяжкасцяў.
Усталяванне пакета праз GUI
На Mac, большасць дыскавых вобразаў .dmg утрымліваюць пакеты .app. Адкрываем падвойнай пстрычкай дыскавая выява, пасля чаго які капіюецца пакет, да прыкладу, перацягваючы яго ў /Applications у Finder. Для мяне гэта само сабой зразумела, але я чуў, што некаторыя навічкі могуць не здужаць такое. Па-змаўчанні Apple "прапануе" агульнасістэмны каталог /Applications (на NeXT ён быў сеткавы, а таксама індывідуальны), але можна лёгка змясціць свае прыкладанні на файлавы сервер або ў падкаталог $HOME/Applications, калі вам так падабаецца.
На Haiku, падвойная пстрычка па пакеце, потым пстрычка па «Install», прасцей няма куды. Мне вось цікава, а што адбудзецца, калі ў пакета ёсць залежнасці, даступныя ў HaikuPorts, але пакуль яшчэ не ўсталяваныя. На Linux на самай справе не ведаюць, што рабіць у гэтай сітуацыі, але ж рашэнне відавочна – спытаць карыстальніка, ці трэба загрузіць і ўсталяваць залежнасці. Дакладна тое, што робіць Haiku.
Я запампаваў пакет 'sanity' уручную і пстрыкнуў па ім, пакетны мэнэджар ведае, адкуль узяць яго залежнасці (пры ўмове, што рэпазітары ўжо прапісаны ў сістэме). Не кожны дыстрыбутыў Linux такое ўмее.
Яшчэ адзін спосаб – выкарыстанне файлавага мэнэджара, дастаткова перацягнуць .hpkg пакет або ў /Haiku/system/packages (для агульнасістэмнай усталёўкі, па-змаўчанні), або ў /Haiku/home/config/packages (для індывідуальнай усталёўкі; недаступна пры падвойнай пстрычцы - мяне ўсё яшчэ ятрыць слова "config" у гэтым месцы, якое для мяне ў дадзеным выпадку сінонім "settings"). Хоць канцэпцыя некалькіх карыстачоў яшчэ нават не даступная для Haiku (напэўна, таму ўсё так проста — я не ведаю, можа, шматкарыстальніцкія магчымасці залішне ўскладняць рэчы для працоўнага асяроддзя персанальнага кампутара).
У гэтай катэгорыі перамагае Haiku, таму што ўмее працаваць не толькі з праграмамі, але і з сістэмнымі праграмамі.
Выдаленне пакета з GUI
На Mac, трэба перацягнуць абразок прыкладання ў кошык, і на гэтым усё. Лёгка!
На Haiku, па-першае, трэба знайсці, дзе знаходзіцца пакет у сістэме, таму што вы рэдка калі ўсталюеце яго куды трэба (усё робіць сістэма). Звычайна шукаць трэба ў /Haiku/system/packages (пры агульнасістэмнай усталёўцы па-змаўчанні), або ў /Haiku/home/config/packages (я ўжо казаў, што "config" - няправільная назва?). Потым дадатак проста перацягваецца ў кошык, і на гэтым усё.
Лёгка! Зрэшты, я б так не сказаў. Вось што адбываецца насамрэч:
Вось што атрымліваецца, калі перацягнуць прыкладанне ў кошык з /Haiku/system/packages
Проста паспрабаваў перамясціць у кошык сваё ўчорашняе прыкладанне "Прывітанне, мір" на QtQuickApp. Я не спрабаваў перамясціць сістэмны каталог, а паколькі ўсе пакеты ўсталёўваюцца ў сістэмны каталог - немагчыма выдаліць пакет .hpkg без змены «яго змесціва». Звычайны карыстальнік спалохаўся б, націснуў бы кнопку "Адмена", прызначаную па-змаўчанні.
Тлумачыць :
Гэтаму паведамлення ўжо больш за 10 гадоў. Хутчэй за ўсё нам трэба наладзіць яго так, каб папярэджанне вылазіць толькі пры перасоўванні самога пакета. Звычайным карыстальнікам у любым выпадку не трэба так рабіць.
Добра, магчыма, трэба зрабіць гэта, выкарыстоўваючы HaikuDepot? Пстрыкаю двойчы па пакеце ў /Haiku/system/packages, чакаючы, што здасца кнопка "Uninstall". Не-а, ёсць (толькі) "Install". "Uninstall", дзе ты?
Для прыколу паспрабаваў паглядзець, што здарыцца, калі я націсну «Install» для ўжо ўсталяванага пакета. Атрымліваецца так:
Гэта атрымліваецца, калі вы спрабуеце ўсталяваць ужо ўсталяваны пакет.
Следам з'яўляецца:
Калі націснуць "Apply changes" у папярэднім акне - атрымаецца так
Мяркую, што гэта праграмная памылка, спасылка на заяўку ўжо ёсць. [аўтар спасылку не падаў, - заўв. перакладчыка]
Хуткае рашэнне: Дадаць кнопку "Uninstall", калі пакет ужо ёсць у
/Haiku/system/packages, Або ў/Haiku/home/config/packages.
Пры праглядзе спісу пакетаў, усталяваных у HaikuDepot, я бачу свой пакет у спісе і магу выдаліць яго.
У гэтай катэгорыі перамагае Mac. Але я магу ўявіць, што пры належнай наладзе карыстацкі досвед на Haiku будзе лепш, чым на Mac. (Адзін з распрацоўнікаў ацаніў гэта так: «Менш за гадзіну для дадання паказанага функцыяналу ў HaikuDepot, калі вы крыху ведаеце З++», ёсць добраахвотнікі?)
Выдаленне чаго-небудзь з пакета
Давайце паспрабуем выдаліць само дадатак, а не пакет .hpkg, з якога яно з'явілася (сумняваюся, што для "простых смяротных" ёсць якая-небудзь розніца).
На Mac, карыстальнік на самай справе звычайна працуе з файлам .dmg, адкуль бярэцца пакет прыкладання .app. Звычайна вобразы .dmg назапашваюцца ў каталогу загрузак, пакеты ж капіююцца карыстачом у /Applications. Ёсць меркаванне, што шматлікія карыстачы самі не ведаюць, што яны робяць, гэтая гіпотэза пацвярджаецца былым супрацоўнікам Apple. (Адна з рэчаў, якая мне не падабаецца на Mac. А, да прыкладу, з AppImage няма розніцы паміж прыкладаннем і пакетам, у якім яно было. Перацягнулі абразок у кошык = вось і ўсё. Лёгка!)
На Haiku, таксама ёсць падзел паміж apps/ и packages/, так што я сумняваюся, што карыстальнікам ад гэтага стала больш зразумела. А вось што адбываецца, калі перацягнуць дадатак з apps/ у кошык:
Вось што атрымліваецца пры спробе выдалення прыкладання, узятага з файла .hpkg
Тэхнічна яно правільна (бо дадатак размешчана на файлавай сістэме толькі для чытання, у першую чаргу), але гэта не асоба карысна карыстачу.
Хуткае рашэнне: замест гэтага прапанаваць праз GUI выдаліць
.hpkg
Для прыколу я паспрабаваў дубляваць дадатак, націснуўшы Alt+D. Атрымаў паведамленне "Немагчыма перамясціць або капіяваць аб'екты на томе толькі для чытання". А ўсё таму, што /system (акрамя /system/packages и /system/settings) з'яўляецца кропкай мантавання packagefs (памятаеце, як яна з'яўляецца ў выснове df?). На жаль, вывад каманды mount не растлумачвае сітуацыю (як і было сказана ў адной з папярэдніх артыкулаў), mountvolume не паказвае шуканае (па ўсёй бачнасці якія мантуюцца праз loop пакеты .hpkg не лічацца «томамі»), а таксама я забыўся на альтэрнатыўныя каманды.
У гэтай катэгорыі ніхто не перамог, акрамя AppImage (але гэта, калі зусім сапраўды, прадузятае меркаванне). Аднак можна ўявіць, што пасля падладкі, карыстацкі досвед на Haiku будзе лепш, чым на Mac.
Заўвага: трэба высветліць, што такое "том" па адносінах у "частцы". Верагодна, гэта падобна стаўленню "тэчкі" да "каталогу": большасць каталогаў адлюстроўваюцца ў файлавым мэнэджары ў выглядзе тэчак, але не ўсе з іх (напрыклад, пакеты, апрацоўваныя як файлы). Падобныя выкладкі робяць мяне нердам афіцыйна?
Капіраванне змесціва пакета на іншую сістэму
На Mac, тупа перацягваю пакет .app, а паколькі залежнасці ўнутры пакета - яны перамяшчаюцца разам.
На Haiku, перацягваю дадатак, але залежнасці не апрацоўваюцца наогул.
Хуткае рашэнне: Няхай замест гэтага прапануецца перацягнуць пакет ``.hpkg цалкам, разам з залежнасцямі, пры іх наяўнасці.
У гэтай катэгорыі адназначна перамагае Mac. Прынамсі для мяне, аматара іх парадыгмы. На Haiku трэба было б скапіяваць .hpkg замест дадатку, але сістэма не прапануе мне такога…
Спампоўка пакета з усімі яго залежнасцямі
Не кожная машына падключана да сеткі ўвесь час. Наадварот, некаторыя машыны (так, я гляджу на вас, сучасныя Windows, Mac і Linux) забываюць пра гэта. Для мяне важна, што я магу пайсці да прыкладу ў Інтэрнэт-кафэ, напампаваць софту на здымны носьбіт, уставіць гэты носьбіт у хатні кампутар і быць упэўненым, што ўсё спрацуе. перакладчыка].
У выніку крыху часцей, чым заўсёды, я звычайна атрымліваю незадаволеныя залежнасці на Windows і Linux.
На Mac гэта звычайна адзін файл, усё што трэба .dmg. Часцей за ўсё ў яго няма залежнасцяў, акрамя тых, што прадастаўляюцца самой MacOS па-змаўчанні. У якасці выключэння можна прывесці складаныя прыкладанні, якія патрабуюць якое адпавядае асяроддзі выканання, да прыкладу java.
На Haiku спампаваць пакет .hpkg для, скажам, таго ж прыкладанні на java, можа апынуцца недастатковым, паколькі java можа як прысутнічаць, так і адсутнічаць на мэтавай машыне. Ці ёсць спосаб спампаваць усе залежнасці для дадзенага пакета .hpkg, Акрамя тых, якія ўстанаўліваюцца ў Haiku па-змаўчанні і, такім чынам, павінны быць у кожнай сістэме Haiku?
У гэтай катэгорыі з невялікім адрывам перамагае Mac.
Каментуе mr. waddlesplash:
Для таго, каб напісаць праграму для збору ўсіх залежнасцяў прыкладання ў выглядзе набору пакетаў
.hpkgдля каго-небудзь, знаёмага з унутранай прыладай Haiku, дастаткова каля 15 хвілін. Дадаць падтрымку для гэтага не так ужо і складана, калі ў гэтым ёсць рэальная галеча. Але для мяне гэта рэдкая сытуацыя.
Затрымаем дыханне да наступнага артыкула ў гэтым цыкле.
Перамяшчэнне пакетаў у адасобленае месца
Як я ўжо пісаў раней, хачу змясціць мае пакеты .hpkg (ну, ці частка іх) у адмысловае месца, адасобленае ад звычайнага размяшчэння на загрузным томе (каранёвай частцы). У звычайным выпадку (не такім ужо і тэарэтычным) чыннік таму - тое, што ўвесь час сканчаецца вольнае месца на маіх (убудаваных) кружэлках, без розніцы наколькі яны вялікія. І я звычайна падключаю вонкавыя дыскі ці сеткавыя рэсурсы, дзе знаходзяцца мае прыкладанні.
На Mac я проста перамяшчаю пакеты .app на здымны дыск або сеткавы каталог у Finder, і на гэтым усё. Я ўсё яшчэ магу падвойнай пстрычкай адкрыць прыкладанне як звычайна я гэта рабіў з загрузнага тома. Проста!
На Haiku, як мне сказалі, гэтага можна дасягнуць шляхам перамяшчэння маіх .hpkg пакетаў на здымную кружэлку або сеткавы каталог, але потым трэба скарыстацца некаторымі недакументаванымі камандамі ў кансолі для таго, каб змантаваць іх у сістэму. Я не ведаю, як гэта зрабіць, выкарыстоўваючы толькі GUI.
У гэтай катэгорыі перамагае Mac.
Згодна з mr. waddlesplash:
Тут аптымізацыя з разліку нармальнага прымянення. Калі ж будзе попыт большы, чым у аднаго карыстальніка, мы рэалізуем гэта. У любым выпадку ёсць магчымасць іншай рэалізацыі.
Пра гэта раскажам у наступным артыкуле.
Калі казаць пра сеткавыя каталогі: было б выдатна (мяркую LAN вечарынкі) мець простыя, якія выяўляюцца, агульнасеткавыя прыкладанні (напрыклад, па Zeroconf), якія можна скапіяваць на лакальны кампутар або запусціць адразу з лакальнай сеткі. Вядома ж, у распрацоўшчыкаў ёсць магчымасць адмовы праз app_flags.
Выніковая справаздача па інтэграцыі сістэмы hpkg c GUI
Я думаю, што найперш з-за адноснай навізны інтэграцыя. .hpkg з GUI ўсё яшчэ пакідае жадаць лепшага. Ва ўсякім разе, ёсць некалькі рэчаў, якія можна палепшыць па частцы UX.
Яшчэ адна рэч: Kernel Debug Land
Было б шыкоўна пры kernel panic мець магчымасць уводзіць каманды, да прыкладу syslog | grep usb. Ну, на Haiku гэта магчыма дзякуючы Kernel Debug Land. Як жа ўбачыць гэтую магію ў дзеянні, калі ў вас усё працуе як трэба без траплення ў kernel panic? Лёгка, націснуўшы Alt+PrintScn+D (мнемоніка Debug). Мне адразу ўспамінаюцца , якая дазваляла першапачатковым распрацоўнікам 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, фармаваныя . Для ўстаноўкі дастаткова спампаваць вобраз і запісаць яго на флэшку з дапамогай
Зьявіліся пытаньні? Запрашаем вас у рускамоўны .
Агляд памылак:
Ад перакладу: гэта шосты артыкул з цыклу пра Haiku.
Спіс артыкулаў:
Крыніца: habr.com