Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave

TL; DR: Haiku është një sistem operativ i krijuar posaçërisht për PC, kështu që ka disa truke që e bëjnë mjedisin e tij desktop shumë më të mirë se të tjerët. Por si funksionon?

Kohët e fundit Zbulova Haikun, një sistem të mirë të papritur. Unë jam ende i habitur se sa mirë funksionon, veçanërisht në krahasim me mjediset e desktopit Linux. Sot do të hedh një vështrim nën kapuç. Aty ku është e nevojshme për një kuptim të thellë, unë do të bëj krahasime me mjediset origjinale të desktopit Macintosh, Mac OS X dhe Linux (standardi XDG nga freedesktop.org).

Burimet në skedarët ELF

Dje mësova se IconOMatic mund të ruajë ikona në burimet rdef në ekzekutuesit ELF. Sot dua të shoh se si funksionon vërtet.

Burimet? citim nga Bruce Horn, autori origjinal i Macintosh Finder dhe "babai" i Menaxherit të Burimeve Macintosh:

Unë jam i shqetësuar për natyrën e ngurtë të kodimit tradicional. Për mua, vetë ideja e një aplikacioni të ngrirë në kod, pa aftësinë për të ndryshuar asgjë në mënyrë dinamike, është egërsia më e egër. Duhet të jetë e mundur të ndryshohet sa më shumë që të jetë e mundur në kohën e ekzekutimit. Sigurisht, vetë kodi i aplikacionit nuk mund të ndryshohet, por me siguri diçka mund të ndryshohet pa ripërpiluar kodin?

Në Macintosh origjinal, ata bënë që këta skedarë të kenë një "seksion të dhënash" dhe një "seksion burimesh", gjë që e bëri jashtëzakonisht të lehtë ruajtjen e gjërave si ikonat, përkthimet dhe të ngjashme. në skedarët e ekzekutueshëm.

Në Mac kjo përdoret Riredakto, një program grafik për - papritmas - redaktimin e burimeve.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Riredakto në Macintosh origjinal

Si rezultat, u bë i mundur redaktimi i ikonave, artikujve të menusë, përkthimeve, etj. mjaft lehtë, por ata ende "udhëtojnë" me aplikacionet.
Në çdo rast, kjo qasje kishte një pengesë të madhe: funksionoi vetëm në sistemet e skedarëve Apple, gjë që ishte një nga arsyet pse Apple braktisi "seksionin e burimeve" kur kaloi në Mac OS X.
Në Mac OS X, Apple donte një zgjidhje të pavarur nga sistemi i skedarëve, kështu që ata adoptuan konceptin e paketave (nga NeXT), drejtoritë që trajtohen si "objekte të errët" nga menaxheri i skedarëve, si skedarë dhe jo drejtori. Çdo paketë me një aplikacion në format .app ka ndër të tjera një dosje Info.plist (në një lloj ekuivalenti të Apple të JSON ose YAML) që përmban të dhëna meta të aplikacionit.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Çelësat për skedarin Info.plist nga paketa e aplikacionit Mac OS X.

Burimet, të tilla si ikonat, skedarët UI dhe të tjera, ruhen në paketë si skedarë. Koncepti në fakt u kthye në rrënjët e tij në NeXT.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Mathematica.app në NeXTSTEP 1.0 në 1989: shfaqet si një direktori skedarësh në terminal, por si një objekt i vetëm në menaxherin e skedarëve grafik.

Le të kthehemi te BeOS, konceptet mbi të cilat bazohet Haiku. Zhvilluesit e tij, kur kaluan nga PEF (PowerPC) në ELF (x86) (njëlloj si përdoret në Linux), vendosën të shtojnë një seksion burimesh në fund të skedarëve ELF. Ai nuk përdori seksionin e tij të duhur ELF, ai thjesht u shtua në fund të skedarit ELF. Si rezultat i programit strip dhe të tjerët nga binutils, të pavetëdijshëm për këtë, thjesht e ndërprenë atë. Prandaj, kur shtoni burime në një skedar ELF në BeOS, është më mirë të mos manipuloni me mjete Linux.

Çfarë po ndodh me Haikun tani? Në thelb, pak a shumë e njëjta gjë.

Në teori, do të ishte e mundur të vendosni burime në seksionin e dëshiruar të ELF. Sipas zhvilluesve në kanalin #haiku në irc.freenode.net:

Me ELF seksioni do të kishte më shumë kuptim... e vetmja arsye pse nuk po e bëjmë në këtë mënyrë është sepse është ajo që bëmë në BeOS."
Dhe nuk ka kuptim ta ndryshojmë këtë tani.

Manaxhimi i burimeve

Burimet shkruhen në një format të strukturuar "burimi": në thelb një listë burimesh me madhësi dhe më pas përmbajtjen e tyre. e kujtova format ar.
Si të kontrolloni burimet në Haiku? A ka diçka si ResEdit?
Sipas dokumentacionin:

Për të parë burimet e ofruara në paketën e aplikacionit, mund të tërhiqni skedarin e ekzekutueshëm në një program si Burimtar. Ju gjithashtu mund të shkoni në terminal dhe të ekzekutoni komandën listres имя_файла.

Resourcer është i disponueshëm në HaikuDepot, por ai thjesht prishet për mua.

Si të menaxhoni burimet në skedarët ELF? Duke përdorur rsrc и rdef. rdef dosjet janë mbledhur në rsrc. Skedari rdef ruhet në format teksti të thjeshtë, kështu që është shumë më e lehtë për të punuar me të. Formati i skedarit rsrc bashkangjitur në fund të skedarit ELF. Le të përpiqemi të luajmë:

~> 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

Ju mund të përdorni programin xres për kontroll dhe kontroll:

/> 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.
(...)

Mirë, le të provojmë?

/> 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

Më shumë rreth burimeve dhe formatit rdef ju mund të lexoni këtu.

Llojet standarde të burimeve

Megjithëse mund të vendosni çdo gjë në burime, ekzistojnë disa lloje standarde të përcaktuara:

  • app_signature: Lloji i aplikacionit MIME, për hartimin e skedarëve të hapur, nisjen, IPC, etj.
  • app_name_catalog_entry: Meqenëse emri i aplikacionit është zakonisht në anglisht, mund të specifikoni vendet ku ndodhen emrat e përkthyer, në mënyrë që përdoruesit e gjuhëve të ndryshme të shohin emrin e aplikacionit të përkthyer nëse dëshironi.
  • app_version: pikërisht ajo që keni menduar
  • app_flags: tregon registrar si të përpunohet aplikacioni. Mendoj se ka më shumë nga sa duket. Për shembull, ekziston B_SINGLE_LAUNCH, i cili e detyron sistemin të nisë një proces të ri aplikimi sa herë që përdoruesi e kërkon atë (i njëjti parim përdoret për shumicën e aplikacioneve në Linux). Hani B_MULTIPLE_LAUNCH, duke bërë që procesi të funksionojë çdo skedar. Më në fund ka B_EXCLUSIVE_LAUNCH, e cila e detyron sistemin të nisë vetëm një proces në të njëjtën kohë, pavarësisht sa shpesh përdoruesit e nisin atë (për shembull, kështu funksionon Firefox në Linux; i njëjti rezultat mund të arrihet në aplikacionet Qt duke përdorur funksionin QtSingleApplication). Aplikimet me B_EXCLUSIVE_LAUNCH njoftohen kur përdoruesi përpiqet t'i ekzekutojë përsëri: për shembull, ata marrin shtegun e skedarit që përdoruesi dëshiron të hapë me ndihmën e tyre.
  • vector_icon: Ikona e aplikacionit vektor (BeOS nuk kishte ikona vektoriale, shumica e aplikacioneve kishin dy ikona raster në skedarët e tyre të ekzekutueshëm).

Sigurisht, ju mund të shtoni burime me çdo ID dhe lloj të dëshiruar, dhe më pas t'i lexoni ato në vetë aplikacionin ose aplikacione të tjera duke përdorur klasën BResources. Por së pari, le të shohim temën magjepsëse të ikonave.

Ikona vektoriale në stilin Haiku

Natyrisht, jo vetëm Haiku zgjodhi formatin më të mirë të ikonave; në këtë pjesë, situata me mjediset e desktopit Linux nuk është aspak ideale:

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

Duke parë këtë, tashmë mund të ndjeni se çfarë pjese është.

Sigurisht, ka shkallëzues, i cili përmban, siç mund ta kuptoni, ikona vektoriale. Pse atëherë ka ndonjë gjë tjetër? Sepse rezultati i vizatimit të grafikave vektoriale në madhësi të vogla mund të jetë më pak se ideal. Do të doja të kisha opsione të ndryshme të optimizuara për madhësi të ndryshme. Në mjediset e desktopit Linux, kjo arrihet duke shpërndarë ikona të madhësive të ndryshme në të gjithë sistemin e skedarëve.

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

Ju lutemi vini re: nuk ka asnjë koncept të versioneve të ndryshme të Firefox. Kështu, nuk është e mundur të trajtohet me hijeshi situatën e të pasurit versione të shumta të një aplikacioni në sistem.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Ikona të ndryshme Firefox në versione të ndryshme. Aktualisht është e pamundur ta trajtosh këtë në Linux pa paterica të ndryshme.

Mac OS X e trajton atë pak më delikate:

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

Mund të shihet se ka një skedar firefox.icns në paketë Firefox.app, që përmban të gjitha madhësitë në mënyrë që versione të ndryshme të të njëjtit aplikacion të kenë ikona të ndryshme.
Shumë më mirë! Ikonat udhëtojnë me aplikacionin, të gjitha burimet janë në një skedar.

Le të kthehemi te Haiku. Një zgjidhje marramendëse, pa përjashtime. Sipas dokumentacionin:

U zhvillua një format i veçantë HVIF, shumë i optimizuar për madhësi të vogla dhe interpretim të shpejtë. Prandaj, ikonat tona në pjesën më të madhe janë shumë më të vogla sesa në raster ose në formatin SVG të përdorur gjerësisht.

Dhe ato janë ende të optimizuara:

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Madhësitë e ikonave në HVIF në krahasim me formatet e tjera.

Dallimi është një rend i madhësisë!

Por magjia nuk mbaron këtu. I njëjti HVIF mund të tregojë nivele të ndryshme detajesh në varësi të madhësisë së shfaqur, edhe pse është një format vektori.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Nivele të ndryshme detajesh (LOD) në varësi të madhësisë së renderit

Tani në lidhje me disavantazhet: nuk mund të merrni SVG, ta hidhni në ImageMagick dhe ta quani një ditë; duhet të kaloni disa cikle për të krijuar një ikonë në formatin HVIF. Këtu shpjegimet. Megjithatë, IconOMatic mund të importojë SVG në mënyrë mjaft të papërsosur; rreth 90% e detajeve SVG importohen me njëfarë probabiliteti, pjesa e mbetur prej 10% do të duhet të konfigurohet dhe ndryshohet manualisht. Lexoni më shumë se si HVIF bën magjinë e tij një mund të në blog Leah Ganson

Shtimi i një ikone në aplikacion

Tani mund të shtoj një ikonë në paketën e krijuar Herën e fundit, duke marrë parasysh të gjithë informacionin e marrë.
Epo, meqenëse nuk jam veçanërisht i etur të vizatoj ikonën time për aplikacionin tim "Hello, World" QtQuickApp tani, e nxjerr atë nga 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

Le të kontrollojmë që ikona është kopjuar:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Duket mirë, por pse ndodh që kur kopjohet ikona e re nuk shfaqet?

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
VICN:101:BEOS:ICONs i kopjuar nuk është përdorur ende si një ikonë aplikacioni në menaxherin e skedarëve

Çfarë më ka munguar?

Komenti i zhvilluesit:

Duhet të krijojmë një skedar rdef me të gjitha burimet, pastaj ekzekutoni komandën rc имя.rdef, kjo do të krijojë skedarin .rsrc. Pastaj ju duhet të ekzekutoni komandën resattr -o имя_бинарника имя.rsrc. Në minimum, unë përdor komanda si këto për të shtuar ikona në skriptet e mia.

Epo, doja të krijoja një burim, jo ​​një atribut. Jam vërtet konfuz.

Memorie inteligjente duke përdorur sistemin e skedarëve

Hapja dhe leximi i atributeve ELF është i ngadalshëm. Siç shkrova më lart, ikona është shkruar si një burim në vetë skedarin. Kjo metodë është më e besueshme dhe ju lejon t'i mbijetoni kopjimit në një sistem skedar tjetër. Megjithatë, ai më pas kopjohet edhe në atributin e sistemit të skedarëve, për shembull BEOS:ICON. Kjo funksionon vetëm në sisteme të caktuara skedarësh, siç është BFS. Ikonat e shfaqura nga sistemi (në Tracker dhe Deskbar) lexohen nga ky atribut i zgjeruar, sepse kjo zgjidhje funksionon shpejt. Në disa vende (ku shpejtësia nuk është e rëndësishme, për shembull, një dritare tipike "Rreth"), sistemi e merr ikonën direkt nga burimi në skedar. Por ky nuk është fundi. Mos harroni, në Mac, përdoruesit mund të zëvendësojnë ikonat e aplikacioneve, drejtorive, dokumenteve me të tyret, pasi në Mac është e mundur të bëhen këto gjëra "të rëndësishme", për shembull. duke zëvendësuar një ikonë të re Slack me atë të mëparshme. Në Haiku, duhet të mendoni për burimin (në skedar) si ikona origjinale që vjen me aplikacionin dhe atributin (në sistemin e skedarëve BFS) si diçka që lejon përdoruesin të bëjë ndryshime sipas dëshirës (megjithëse, sugjeroni, GUI-ja për futjen e një ikone të personalizuar në krye të ikonës është opsionale). nuk është implementuar ende si parazgjedhje).

Kontrollimi i atributeve të sistemit të skedarëve

Me resaddr Është e mundur të kontrollohen dhe të vendosen atributet e sistemit të skedarëve.

/> 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.
(...)

Është në thelb "ngjitësi" që kryen konvertimin përpara dhe me radhë midis burimeve (të besueshme) dhe atributeve (të shpejta) të sistemit të skedarëve. Dhe meqenëse sistemi pret të marrë burime dhe bën kopjimin automatikisht, nuk do të shqetësohem më për këtë.

Magjia e paketave hpkg

Aktualisht (më shpesh) paketat përdoren për të marrë programe në Haiku .hpkg. Mos u mashtroni nga emri i thjeshtë: formati .hpkg funksionon krejtësisht ndryshe nga formatet e tjera me emra të ngjashëm që keni hasur, ai ka superfuqi të vërteta.

Me formatet tradicionale të paketave, u mërzita për një kohë të gjatë për shkak të këtij fakti: ju shkarkoni një gjë (paketë) dhe një tjetër instalohet në sistem (skedarët brenda paketës). Menaxhimi i skedarëve (për shembull, fshirja e tyre) është mjaft i vështirë kur instaloni një paketë në mënyrën tradicionale. Dhe të gjitha për shkak të përmbajtjes së paketës të shpërndara në të gjithë sistemin e skedarëve, duke përfshirë vendet ku përdoruesi mesatar mund të mos ketë akses për shkrim. Kjo krijon një klasë të tërë programesh - menaxherët e paketave. Por transferimi i softuerit të instaluar tashmë, për shembull, në një makinë tjetër, disk të lëvizshëm ose server skedarësh bëhet edhe më i vështirë, nëse jo plotësisht i pamundur. Në një sistem tipik të bazuar në Linux, mund të ketë lehtësisht disa qindra mijëra deri në miliona skedarë individualë. Eshtë e panevojshme të thuhet se kjo është edhe e brishtë dhe e ngadaltë, për shembull kur instaloni fillimisht një sistem, kur instaloni, përditësoni dhe çinstaloni paketat e rregullta dhe kur kopjoni vëllimin e nisjes (ndarjen rrënjë) në një medium tjetër.

Unë jam duke punuar në projektin AppImage, një patericë e pjesshme për aplikacionet e përdoruesve fundorë. Ky është një format shpërndarjeje softueri që mbledh një aplikacion dhe të gjitha varësitë e tij në një imazh të vetëm të sistemit të skedarëve që montohet kur fillon aplikacioni. Thjeshton në mënyrë të konsiderueshme gjërat, pasi i njëjti ImageMagick kthehet papritur në një skedar të vetëm, i menaxhuar në një menaxher skedari nga njerëz të thjeshtë. Metoda e propozuar funksionon vetëm për softuerin, siç pasqyrohet në emrin e projektit, dhe gjithashtu ka grupin e vet të problemeve, pasi njerëzit e përfshirë në ofrimin e softuerit për Linux gjithmonë e drejtojnë shigjetën drejt meje.

Le të kthehemi te Haiku. A ka qenë e mundur të gjendet ekuilibri optimal midis sistemeve tradicionale të paketave dhe ofrimit të softuerit të bazuar në imazhe? Paketat e saj .hpkg në fakt imazhet e kompresuara të sistemit të skedarëve. Kur sistemi niset, kerneli monton të gjitha paketat e instaluara dhe aktive me përafërsisht mesazhet e mëposhtme të kernelit:

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"

E bukur, po? Rri aty, do të jetë edhe më i freskët!

Ekziston një paketë shumë e veçantë:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Ai përmban një sistem operativ shumë minimalist, duke përfshirë kernelin. Besoni apo jo, edhe vetë kerneli nuk hiqet nga vëllimi i nisjes (ndarja rrënjësore), por ngarkohet me kujdes në vendin e tij nga paketa. .hpkg. Uau! Unë e kam përmendur tashmë se mendoj se një pjesë e sofistikimit dhe qëndrueshmërisë së përgjithshme të Haikut vjen nga fakti se i gjithë sistemi, nga kerneli dhe hapësira kryesore e përdoruesve deri te menaxhimi i paketave dhe infrastruktura e kohës së funksionimit, zhvillohet në bashkëpunim nga një ekip. Imagjinoni sa grupe dhe ekipe të ndryshme do të duheshin për të ekzekutuar diçka të tillë në Linux [Unë imagjinoj projektin PuppyLinux - përafërsisht. përkthyes]. Pastaj imagjinoni sa kohë do të duhet që kjo qasje të miratohet në shpërndarje. Ata thonë: merrni një problem të thjeshtë, ndajeni atë midis interpretuesve të ndryshëm dhe do të ndërlikohet aq shumë sa nuk do të jetë më e mundur ta zgjidhni atë. Haiku në këtë rast m'i hapi sytë. Unë mendoj se kjo është pikërisht ajo që po ndodh në Linux tani (Linux në këtë rast është një term kolektiv për pirgun Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Rikthimi i sistemit duke përdorur hpkg

Sa shpesh ndodh situata e mëposhtme: përditësimi ishte i suksesshëm dhe më pas rezulton se diçka nuk po funksionon siç duhet? Nëse përdorni menaxherët e paketave konvencionale, është e vështirë të ktheni gjendjen e sistemit në një moment në kohë përpara se të instaloheshin paketat e reja (për shembull, në rast se diçka nuk shkonte). Disa sisteme ofrojnë zgjidhje në formën e fotografive të sistemit të skedarëve, por ato janë mjaft të rënda dhe nuk përdoren në të gjitha sistemet. Haiku e zgjidh këtë duke përdorur paketat .hpkg. Sa herë që ndryshojnë paketat në sistem, paketat e vjetra nuk fshihen, por ruhen në sistem në nëndrejtori si p.sh. /Haiku/system/packages/administrative/state-<...>/ vazhdimisht. Operacionet e papërfunduara ruajnë të dhënat e tyre në nëndrejtori /Haiku/system/packages/administrative/transaction-<...>/.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
përmbajtje /Haiku/system/packages/administrative. Drejtoritë "gjendja..." përmbajnë skedarë teksti me emrat e paketave aktive, dhe drejtoritë "transaksioni..." përmbajnë vetë paketat.

“Gjendja e vjetër aktive”, d.m.th. listë .hpkg paketat aktive përpara ndryshimeve regjistrohen pas çdo operacioni në menaxherin e skedarëve në një skedar teksti /Haiku/system/packages/administrative/state-<...>/activated-packages. Në mënyrë të ngjashme, një "gjendje aktive" e re shkruhet në një skedar teksti /Haiku/system/packages/administrative/activated-packages.

Drejtoria /Haiku/system/packages/administrative/state-<...>/ përmban vetëm një skedar teksti me një listë të paketave aktive të kësaj gjendje (në rast të instalimit të paketave pa hequr), dhe nëse paketat janë hequr ose përditësuar - drejtoria e shtetit përmban versione të vjetra të paketave.

Kur sistemi niset, bazuar në listën e paketave, merret një vendim për aktivizimin (montimin) e paketave. Është kaq e thjeshtë! Nëse diçka shkon keq gjatë shkarkimit, mund t'i thoni menaxherit të shkarkimit të përdorë një listë tjetër, më të vjetër. Problemi u zgjidh!

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Shkarkues Haiku. Çdo pikë hyrje shfaq një "gjendje aktive" përkatëse

Më pëlqen qasja e të pasurit skedarë teksti të thjeshtë si lista e "gjendjes aktive", me emra që janë të lehtë për t'u kuptuar .hpkg. Kjo qëndron në kontrast të plotë me të qenit i ndërtuar për-makinat-jo-për-njerëzit. në një bandë nga OSTree ose Flatpak në sistemin e skedarëve (në të njëjtin nivel me Microsoft GUID).

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Lista e paketave aktive për çdo moment në kohë

Të dhënat e konfigurimit

Me sa duket, në katalog /Haiku/system/packages/administrative/writable-files përmban skedarë konfigurimi për paketat, por ato janë të shkrueshme. Në fund të fundit, siç e mbani mend, .hpkg montuar vetëm për lexim. Pra, këto skedarë duhet të kopjohen nga paketat përpara se të shkruani. Ka kuptimin.

Integrimi GUI për sistemin .hpkg

Le të shohim tani se si këto çanta me shkëlqim .hpkg përballen me integrimin në mjedisin e punës së përdoruesit (UX). Në fund të fundit, Haiku është menduar për përdorim personal, në fund të fundit. Personalisht, kam vendosur shiritin lart kur krahasoj përvojën e përdoruesit me paketat .app në Macintosh me të njëjtën përvojë në .hpkg. Unë as nuk do ta krahasoj situatën me mjediset e punës në Linux, sepse është absolutisht e tmerrshme në krahasim me çdo tjetër.

Më vijnë në mendje skenarët e mëposhtëm:

  • Unë dua të shikoj përmbajtjen e një pakete .hpkg
  • Unë dua të instaloj një paketë
  • Unë dua të heq paketimin
  • Dua të heq diçka që hyri në sistem si pjesë e një pakete
  • Dua të kopjoj diçka që hyri në sistem si pjesë e një pakete
  • Unë dua të shkarkoj të gjitha varësitë e një pakete, e cila mund të mos jetë pjesë e çdo instalimi Haiku (për shembull, unë kam një makinë të izoluar fizikisht pa akses në internet.)
  • Unë dua t'i zhvendos paketat e mia (ose një pjesë të tyre) veçmas në një vend tjetër, të ndarë nga vëllimi i nisjes (ndarja rrënjësore) (sepse, për shembull, nuk kam hapësirë ​​të mjaftueshme në të).

Kjo duhet të mbulojë shumicën e rasteve kryesore nga puna ime e përditshme. Epo, le të fillojmë.

Kontrollimi i përmbajtjes së paketës

Në Mac Unë thjesht kliko me të djathtën mbi paketën për ta hapur dhe për të parë përmbajtjen në Finder. Në fund të fundit, në realitet është thjesht një drejtori i maskuar! (E di që ka pako .pkg për një pjesë të sistemit që nuk është aplikacione, por përdoruesit e zakonshëm më shpesh nuk ndërveprojnë me ta).

Në Haiku Unë kliko me të djathtën mbi paketën, pastaj kliko "Përmbajtja" për të parë se çfarë ka brenda. Por këtu është vetëm një listë e skedarëve pa aftësinë për t'i hapur ato duke klikuar dy herë.
Do të ishte shumë më mirë nëse do të kishte një mënyrë për të montuar (përkohësisht) paketën .hpkg të shikohet përmes një menaxheri skedari dhe përdoruesi nuk do të duhet të shqetësohet për detajet e zbatimit. (Nga rruga, ju mund të hapni .hpkg paketë në Expander, i cili mund ta shpaketojë si çdo arkiv tjetër).

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Ndërfaqja e HaikuDepot ju lejon të shikoni një listë të skedarëve të paketës, por nuk ka asnjë mënyrë për të parë përmbajtjen, për shembull, duke klikuar dy herë README.md

Mac fiton në këtë kategori, por shtimi i funksionalitetit HaikuDepot që dëshironi nuk duhet të jetë shumë i vështirë.

Instalimi i një pakete përmes GUI

Në Mac, shumica e imazheve të diskut .dmg përmbajnë paketa .app. Klikoni dy herë mbi imazhin e diskut dhe më pas kopjoni paketën, për shembull, duke e tërhequr atë brenda /Applications në Finder. Kjo është e vetëkuptueshme për mua, por kam dëgjuar se disa të rinj mund të mos jenë në gjendje ta përballojnë këtë. Si parazgjedhje, Apple "sugjeron" një drejtori të gjithë sistemit /Applications (në NeXT ishte i lidhur në rrjet dhe individual), por aplikacionet tuaja mund t'i vendosni lehtësisht në një server skedari ose në një nëndrejtori $HOME/Applications, nëse ju pëlqen kështu.

Në Haiku, klikoni dy herë në paketë, pastaj klikoni "Instalo", nuk mund të ishte më e lehtë. Po pyes veten se çfarë ndodh nëse një paketë ka varësi që janë të disponueshme në HaikuPorts, por të pa instaluara ende. Në Linux ata vërtet nuk dinë se çfarë të bëjnë në këtë situatë, por zgjidhja është e qartë - pyesni përdoruesin nëse duhet të shkarkojnë dhe instalojnë varësi. Pikërisht atë që bën Haiku.

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Unë e shkarkova paketën 'sanity' manualisht dhe klikova mbi të, menaxheri i paketës e di se nga t'i marrë varësitë e tij (duke supozuar se depot janë regjistruar tashmë në sistem). Jo çdo shpërndarje Linux mund ta bëjë këtë.

Një mënyrë tjetër është të përdorni një menaxher skedari, thjesht tërhiqni dhe lëshoni .hpkg paketë ose në /Haiku/system/packages (për një instalim në të gjithë sistemin, si parazgjedhje), ose në /Haiku/home/config/packages (për instalim individual; nuk disponohet kur klikoni dy herë - akoma më shqetëson fjala "config" në këtë vend, që për mua në këtë rast është sinonim i "cilësimeve"). Dhe koncepti i përdoruesve të shumtë nuk është ende i disponueshëm për Haiku-n (ndoshta kjo është arsyeja pse është kaq i thjeshtë - nuk e di, mbase aftësitë e shumë përdoruesve do t'i komplikojnë gjërat në mënyrë të panevojshme për një mjedis desktopi desktop).

Haiku fiton në këtë kategori sepse mund të punojë jo vetëm me aplikacione, por edhe me programe të sistemit.

Heqja e një pakete nga GUI

Në Mac, duhet të tërhiqni ikonën e aplikacionit në koshin e plehrave dhe kjo është e gjitha. Lehtë!

Në Haiku, së pari, duhet të gjeni se ku ndodhet paketa në sistem, sepse rrallë e instaloni atë në vendin e duhur (sistemi bën gjithçka). Zakonisht duhet të shikoni /Haiku/system/packages (me një instalim të paracaktuar në të gjithë sistemin), ose në /Haiku/home/config/packages (A e përmenda se "konfigurimi" është një emërtim i gabuar?). Pastaj aplikacioni thjesht tërhiqet zvarrë në koshin e plehrave, dhe kjo është ajo.
Lehtë! Megjithatë, nuk do ta thosha këtë. Ja çfarë po ndodh realisht:

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Kjo është ajo që ndodh nëse tërhiqni një aplikacion në koshin e plehrave nga /Haiku/system/packages

Sapo u përpoqa ta zhvendos aplikacionin tim të djeshëm "Hello World" në QtQuickApp në kosh. Unë nuk u përpoqa të lëviz drejtorinë e sistemit, dhe meqenëse të gjitha paketat janë të instaluara në direktorinë e sistemit, është e pamundur të hiqet paketa .hpkg pa ndryshim "përmbajtja e tij". Një përdorues i zakonshëm do të frikësohej dhe do të shtypte butonin "Anulo" të caktuar si parazgjedhje.

Shpjegon Zoti. spërkatje:

Ky postim është mbi 10 vjeç. Me shumë mundësi, ne duhet ta konfigurojmë atë në mënyrë që paralajmërimi të shfaqet vetëm kur vetë paketa të zhvendoset. Përdoruesit e rregullt nuk kanë nevojë ta bëjnë këtë gjithsesi.

Në rregull, ndoshta duhet ta bëj këtë duke përdorur HaikuDepot? Unë klikoj dy herë mbi paketën në /Haiku/system/packages, duke pritur që të shfaqet butoni "Uninstall". Jo, ka (vetëm) "Instalo". "Uinstall", ku jeni?

Vetëm për argëtim, u përpoqa të shikoja se çfarë do të ndodhte nëse klikoja "Instalo" në një paketë të instaluar tashmë. Rezulton kështu:

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Kjo ndodh nëse përpiqeni të instaloni një paketë të instaluar tashmë.

Shfaqet më tej:

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Nëse klikoni "Aplikoni ndryshimet" në dritaren e mëparshme, do të duket kështu

Unë supozoj se ky është një gabim i softuerit; lidhja me aplikacionin është tashmë atje. [autori nuk ka dhënë një lidhje - përafërsisht. përkthyes]

Zgjidhje e shpejtë: Shto një buton "Çinstalo" nëse paketa është tashmë e futur /Haiku/system/packages, ose në /Haiku/home/config/packages.

Kur shikoj listën e paketave të instaluara në HaikuDepot, shoh paketën time në listë dhe mund ta heq atë.

Mac fiton në këtë kategori. Por mund ta imagjinoj që me konfigurimin e duhur, përvoja e përdoruesit në Haiku do të jetë më e mirë se në Mac. (Një nga zhvilluesit e vlerësoi në këtë mënyrë: "Më pak se një orë për të shtuar funksionalitetin e specifikuar në HaikuDepot, nëse dini pak C++", ndonjë vullnetar?)

Heqja e diçkaje nga një paketë

Le të përpiqemi të heqim vetë aplikacionin, jo paketën .hpkg, nga e cila erdhi (dyshoj se për "të vdekshmit e thjeshtë" ka ndonjë ndryshim).

Në Mac, përdoruesi zakonisht punon me skedarin .dmgnga vjen paketa e aplikacionit .app. Zakonisht imazhe .dmg janë grumbulluar në direktorinë e shkarkimeve dhe paketat kopjohen nga përdoruesi në /Applications. Besohet se vetë shumë përdorues nuk e dinë se çfarë po bëjnë, kjo hipotezë konfirmohet nga një ish-punonjës i Apple. (Një nga gjërat që nuk më pëlqen në Mac. Dhe, për shembull, me AppImage nuk ka asnjë ndryshim midis aplikacionit dhe paketës në të cilën ndodhej. Tërhiqeni ikonën te koshi = kaq. Lehtë!)

Në Haiku, ka edhe një ndarje ndërmjet apps/ и packages/, kështu që dyshoj se kjo e bëri më të qartë për përdoruesit. Por çfarë ndodh nëse tërhiqni një aplikacion nga apps/ Shto në shportë:

Dita ime e gjashtë me Haikun: nën kapuçin e burimeve, ikonave dhe paketave
Kjo është ajo që ndodh kur përpiqeni të hiqni një aplikacion të marrë nga një skedar .hpkg

Teknikisht është e saktë (në fund të fundit, aplikacioni është i pritur në një sistem skedari vetëm për lexim në radhë të parë), por nuk është veçanërisht i dobishëm për përdoruesin.

Zgjidhje e shpejtë: sugjeroni përdorimin e GUI-së për të fshirë në vend të kësaj .hpkg

Thjesht për argëtim, provova të dublikoja aplikacionin duke shtypur Alt+D. Mora mesazhin "Nuk mund të lëviz ose kopjoj objekte në një vëllim vetëm për lexim". Dhe të gjitha sepse /system (përveç /system/packages и /system/settings) është pika e montimit të paketave (mbani mend se si shfaqet në dalje df?). Fatkeqësisht, prodhimi i komandës mount nuk e sqaron situatën (siç u tha në një nga artikujt e mëparshëm), mountvolume nuk tregon atë që kërkoni (me sa duket paketat e montuara përmes ciklit .hpkg nuk konsiderohen "vëllime"), dhe kam harruar edhe komandat alternative.

Askush nuk fitoi në këtë kategori përveç AppImage (por ky, për të qenë plotësisht i sinqertë, është një mendim i njëanshëm). Sidoqoftë, mund të imagjinohet që pas ndryshimit, përvoja e përdoruesit në Haiku do të jetë më e mirë se në Mac.

Shënim: duhet të zbuloni se çfarë është një "vëllim" në lidhje me një "seksion". Kjo ndoshta është e ngjashme me marrëdhënien e "folder" me "directory": shumica e drejtorive shfaqen si dosje në menaxherin e skedarëve, por jo të gjitha prej tyre (paketat e trajtuara si skedarë, për shembull). A më bën ky lloj ekrani një budalla zyrtar?

Kopjimi i përmbajtjes së një pakete në një sistem tjetër

Në Mac, E tërheq pakon marrëzi .app, dhe meqenëse varësitë janë brenda paketës, ato lëvizin së bashku.

Në Haiku, e zvarrit aplikacionin, por varësitë nuk përpunohen fare.

Zgjidhje e shpejtë: Në vend të kësaj, le të sugjerojmë zvarritjen e të gjithë paketës `.hpkg, së bashku me çdo varësi, nëse ka.

Mac fiton qartë në këtë kategori. Të paktën për mua, një dashnor i paradigmës së tyre. Duhet ta kopjoj te Haiku .hpkg në vend të një aplikacioni, por sistemi nuk ma ofron këtë...

Shkarkoni një paketë me të gjitha varësitë e saj

Jo çdo makinë është e lidhur me rrjetin gjatë gjithë kohës. Përkundrazi, disa makina (po, po ju shikoj, Windows, Mac dhe Linux modern) e harrojnë këtë. Është e rëndësishme për mua që të mund të shkoj, për shembull, në një kafene interneti, të shkarkoj softuer në një disk të lëvizshëm, ta fus këtë diskun në kompjuterin tim të shtëpisë dhe të jem i sigurt se gjithçka do të funksionojë [djalë i rrezikshëm, duke e bërë këtë në Windows... - përafërsisht. përkthyes].

Si rezultat, prirem të përfundoj me varësi të paplotësuara në Windows dhe Linux pak më shpesh se zakonisht.

Në Mac ky është zakonisht një skedar, gjithçka që duhet të bëni është të shkarkoni .dmg. Më shpesh, ai nuk ka varësi të tjera përveç atyre të ofruara nga vetë MacOS si parazgjedhje. Një përjashtim janë aplikacionet komplekse që kërkojnë një mjedis të përshtatshëm ekzekutimi, për shembull java.

Në Haiku shkarko paketën .hpkg për shembull, i njëjti aplikim në java, mund të mos jetë i mjaftueshëm, pasi java mund ose nuk mund të jetë e pranishme në makinën e synuar. A ka ndonjë mënyrë për të shkarkuar të gjitha varësitë për një paketë të caktuar .hpkg, përveç atyre që janë instaluar si parazgjedhje në Haiku dhe për këtë arsye duhet të jenë në çdo sistem Haiku?

Mac fiton këtë kategori me një diferencë të vogël.

Komentet z. spërkatje me valë:

Për të shkruar një program për të mbledhur të gjitha varësitë e një aplikacioni si një grup paketash .hpkg për dikë që njihet me funksionimin e brendshëm të Haikut, mjaftojnë rreth 15 minuta. Shtimi i mbështetjes për këtë nuk është aq i vështirë nëse ka një nevojë reale për të. Por për mua kjo është një situatë e rrallë.

Le të mbajmë frymën tonë deri në artikullin tjetër të kësaj serie.

Zhvendosja e paketave në një vend të veçantë

Siç kam shkruar më parë, unë dua të vendos paketat e mia .hpkg (pus, ose një pjesë e tyre) në një vend të veçantë, të ndarë nga vendosja e zakonshme në vëllimin e nisjes (ndarja rrënjësore). Në rastin e zakonshëm (jo aq teorik), arsyeja për këtë është se vazhdimisht më mbaron hapësira e lirë në disqet e mia (të integruara), sado të mëdha të jenë. Dhe zakonisht lidh disqet e jashtme ose ndarjet e rrjetit ku ndodhen aplikacionet e mia.

Në Mac Unë thjesht po lëviz paketat .app në një disk të lëvizshëm ose drejtori rrjeti në Finder, dhe kaq. Unë ende mund të klikoj dy herë për të hapur aplikacionin siç do të bëja zakonisht nga vëllimi i nisjes. Vetëm!

Në Haiku, siç më thanë, kjo mund të arrihet duke lëvizur tim .hpkg paketat në një disk të lëvizshëm ose drejtori rrjeti, por më pas ju duhet të përdorni disa komanda të padokumentuara në tastierë për t'i montuar ato në sistem. Nuk di si ta bëj këtë duke përdorur vetëm GUI.

Mac fiton në këtë kategori.

Sipas z. spërkatje me valë:

Ky është një optimizim i bazuar në përdorim normal. Nëse ka kërkesë nga më shumë se një përdorues, ne do ta zbatojmë atë. Në çdo rast, ekziston mundësia e zbatimit nga palët e treta.

Ne do të flasim për këtë në artikullin vijues.

Duke folur për direktoritë e rrjetit, do të ishte mirë (po hamendësoj partitë LAN) të kishim aplikacione të thjeshta, të zbulueshme, në të gjithë rrjetin (si Zeroconf) që mund të kopjohen në kompjuterin lokal ose të ekzekutohen drejtpërdrejt nga rrjeti lokal. Natyrisht, zhvilluesit kanë mundësinë të tërhiqen nëpërmjet app_flags.

Raporti përfundimtar mbi integrimin e sistemit hpkg me GUI

Mendoj se kjo kryesisht për shkak të risive relative të integrimit .hpkg GUI lë ende shumë për të dëshiruar. Gjithsesi, ka disa gjëra që mund të përmirësohen për sa i përket UX...

Një gjë tjetër: Kernel Debug Land

Do të ishte mirë të jesh në gjendje të futësh komanda gjatë panikut të kernelit, për shembull syslog | grep usb. Epo, në Haiku është e mundur falë Kernel Debug Land. Si mund ta shihni këtë magji në veprim nëse gjithçka funksionon siç duhet pa u futur në panik të kernelit? Lehtë duke shtypur Alt+PrintScn+D (Debug mnemonic). Më kujtohet menjëherë Çelësi i programuesit, i cili u lejoi zhvilluesve origjinalë të Macintosh të hynin në korrigjues (nëse ishte i instaluar, sigurisht).

Përfundim

Po filloj të kuptoj se sofistikimi i sistemit Haiku vjen nga fakti që puna kryhet nga një ekip i vogël me fokus të qartë në mjedisin e punës, me të gjitha shtresat e sistemit të aksesueshme.
Një kontrast i mprehtë me botën e Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, ku gjithçka është copëtuar në copa të vogla në një masë të tillë që abstraksioni qëndron mbi abstraksion dhe drejton me paterica.
Kishte gjithashtu një kuptim se si sistemi .hpkg kombinon praktikat më të mira të menaxherëve tradicionalë të paketave, Snappy, Flatpak, AppImage, madje edhe btrfs, dhe i përzien ato me qasjen "vetëm punon" të Mac.

Më dukej sikur diçka "ndërroi" në kokën time dhe kuptova se si sistemi .hpkg di si të rrokulliset, vetëm duke e parë atë. Por nuk jam unë, por bukuria dhe thjeshtësia e sistemit. Pjesa më e madhe e kësaj është frymëzuar nga fryma e Mac origjinal.

Po, shfletimi në shfletues mund të jetë i ngathët dhe të funksionojë si kërmilli, aplikacionet mund të mungojnë (pa Gtk, Electron - zhvilluesit kanë arritur në përfundimin se nuk shkojnë mirë me sofistikimin), video dhe përshpejtimi 3D mund të mungojnë plotësisht, por unë ende i pëlqen ky sistem. Në fund të fundit, këto gjëra mund të korrigjohen dhe ato do të shfaqen herët a vonë. Është vetëm çështje kohe dhe ndoshta paksa e skuqur në sy.

Nuk mund të ofroj ndihmë, por mendoj se do të fillojë që tani viti i Haiku në desktop.

Probleme të rastësishme

Ndoshta tashmë ka kërkesa, apo duhet t'i hap ato?

  • BeScreenCapture duhet të jetë në gjendje të eksportojë në GIF si Peek. Kjo mund të bëhet duke përdorur ffmpeg, tashmë i disponueshëm për Haiku. Aplikacion.
  • Softueri i pamjes së ekranit nuk arrin të regjistrojë një dritare modale, në vend të kësaj kap të gjithë ekranin
  • Ju nuk mund të prisni pamjet e ekranit duke përdorur mjetin prerës të WonderBrush dhe më pas ta ruani rezultatin në një skedar
  • Nuk më pëlqen veçanërisht kursorin e dorës në Haiku, por mendoj se ka të bëjë me ndjenjën e ngrohtë nostalgjike. Kjo është veçanërisht e bezdisshme kur përdorni mjetin e prerjes në Krita, pasi rezulton në prerje të pasaktë (shih pamjet e ekranit të dialogëve modalë në këtë artikull). Një kursor i kryqëzimit do të ishte i mrekullueshëm. Aplikacion.

Provojeni vetë! Në fund të fundit, projekti Haiku ofron imazhe për nisje nga DVD ose USB, të krijuara i përditshëm. Për ta instaluar, thjesht shkarkoni imazhin dhe shkruajeni atë në një flash drive duke përdorur gdhendës

A keni ndonjë pyetje? Ju ftojmë në rusisht-folëse kanali telegram.

Pasqyrë e gabimit: Si të qëlloni veten në këmbë në C dhe C++. Koleksioni i recetave të Haiku OS

Nga autori përkthimi: ky është artikulli i gjashtë i serisë për Haikun.

Lista e artikujve: Первая Dytë Третья i katërt E pesta

Burimi: www.habr.com

Shto një koment