Dita ime e gjashtë me Haiku: nën kapak resurseve, ikonave dhe paketave

TL;DR: Haiku është një sistem operative i dizajnuar veçanërisht për PC, prandaj ka disa truke që e bëjnë mjedisin e saj të punës shumë më të mirë se të tjerët. Por si funksionon ajo?

Kohët e fundit kam zbuluar Haiku, një sistem mjaft të mirë. Ende jam i mahnitur nga sa lehtë funksionon, veçanërisht krahasuar me mjediset e punës në Linux. Sot do të hedh një vështrim nën kapak. Aty ku do të jetë e nevojshme për një kuptim më të thellë, do të bëj një krahasim me Macintosh-in origjinal, Mac OS X dhe mjediset e punës në Linux (standardi XDG nga freedesktop.org).

Burimet në skedarët ELF

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

Burime? Citim nga Bruce Horn, autori origjinal i programit Macintosh Finder dhe "babai" i Macintosh Resource Manager:

Më shqetëson karakteri i forte i kodit tradicional. Për mua vetë ideja e një aplikacioni, i ngrirë në kod, pa mundësi për të ndryshuar diçka dinamikisht - është një barbarizëm i tmerrshëm. Duhet të ketë mundësinë për të bërë sa më shumë ndryshime në kohën e ekzekutimit. Sigurisht, vetë kodi i aplikacionit nuk mund të ndryshohet, por ndonjë gjë mund të ndryshohet edhe pa e rikomplikuar kodin?

Në Macintosh-in origjinal u bë që këta skedarë të kenë "seksion të të dhënave" dhe "seksion të burimeve", që e lehtësoi jashtëzakonisht ruajtjen e gjërave të ndryshme, për shembull ikonave, përkthimeve etj. në skedarët ekzekutivë.

Në Mac për këtë përdoret ResEdit, një program grafik për - befas - redaktimin e burimeve.

ResEdit në Macintosh-in origjinal

Si pasojë, u mundësua redaktimi i ikonave, pikave të menusë, përkthimeve etj. mjaft lehtë, megjithatë ato ende "shkonte" me aplikacionet.
Në çdo rast ky qasje kishte një mangësi të madhe: funksiononte vetëm në sistemet e skedarëve Apple, që u bë një nga arsyet pse Apple hoqi "seksionin e burimeve" kur kaloi në Mac OS X.
Në Mac OS X Apple donin një zgjidhje, e pavarur nga sistemi i skedarëve, prandaj aplikuan konceptin e paketave (nga NeXT), katalogët, të cilat menaxhohen nga menaxheri i skedarëve si "objekte të papashtuara", ashtu si skedarët dhe jo si katalogë. Çdo paketë me aplikacion në formatin .app ka, mes të tjerash, një skedar Info.plist (në një analog të JSON ose YAML nga Apple), që përmban metadata të aplikacionit.

Çelësat e skedës Info.plist nga paketa e aplikacionit Mac OS X.

Burimet, për shembull ikonat, skedarët UI dhe të tjera, ruhen në paketë si skedarë. Koncepti në fakt u rikthye në burimin e tij në NeXT.

Mathematica.app në NeXTSTEP 1.0 në vitin 1989: shfaqet si katalog me skedarë në terminal, por si një objekt i vetëm në menaxherin grafik të skedarëve.

Të kthehemi te BeOS, mbi konceptet e të cilit është ndërtuar Haiku. Zhvilluesit e saj, kur kaluan nga PEF (PowerPC) në ELF (x86) (të njëjtin që përdoret në Linux), vendosën të shtonin një seksion burimesh në fund të skedarëve ELF. Për këtë nuk u përdor një seksion të duhur ELF, thjesht e shkruan në fund të skedarit ELF. Si rezultat, programet strip dhe të tjera nga binutils, që nuk e dinin për këtë, thjesht e prenë atë. Prandaj, duke shtuar burime në skedarin ELF në BeOS, është më mirë të mos punosh me të me mjete Linux.

Çfarë po ndodh tani me Haiku? Në thelb, e njëjta gjë më shumë ose më pak.

Në teori, do të ishte e mundur të vendoseshin burimet në seksionin përkatës ELF. Sipas zhvilluesve në kanalin #haiku në rrjetin irc.freenode.net:

Me ELF, seksioni do të kishte më shumë kuptim ... arsyeja e vetme përse ne nuk veprojmë kështu është se kështu bëhej në BeOS.
Dhe nuk ka kuptim ta ndryshosh këtë tani.

Menaxhimi i burimeve

Burimet shkruhen në një format të strukturuar "burimor": në thelb, kjo është një listë burimesh me përmasat e tyre dhe pastaj përmbajtja e tyre. Më erdhi në mendje formati ar..
Si mund të kontrolloj 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 ekzekutiv te një program si Resourcer. Gjithashtu, mund të hyni në terminal dhe të ekzekutoni komandën listres emri_i_skedarit..

Resourcer është në HaikuDepot, por mua thjesht më ra.

Si mund të menaxhoj burimet në skedarët ELF? Duke përdorur rsrc dhe rdef.. rdef. skedarët kompaktizohen në rsrc. Skedari rdef. ruhet në një format tekstual të zakonshëm, kështu që është shumë më e lehtë të punohet me të. Skedari në formatin rsrc shkruhet në fund të skedarit ELF. Le të provoni të luajmë:

~> rc -h
Haiku Resource Compiler 1.1Për të kompiluar një skenar rdef në një skedar burimi:
    rc [options] [-o ] ...Për të konvertuar një skedar burimi përsëri në një skenar rdef:
    rc [options] [-o ] -d ...Opsionet:
    -d --decompile       krijoni një skenar rdef nga një skedar burimi
       --auto-names      ndërtoni emrat e burimeve nga simbolet ID
    -h --help            tregoni këtë mesazh
    -I --include    shtoni  në listën e rrugëve të përfshirjes
    -m --merge           mos e fshini përmbajtjen ekzistuese të skedarit të daljes
    -o --output          specifikoni emrin e skedarit të daljes, default është out.xxx
    -q --quiet           mos shfaqni asnjë mesazh gabimi
    -V --version         tregoni versionin e softuerit dhe licencën

Mund të përdorni programin xres për të verifikuar dhe menaxhuar:

/> 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. mund të lexoni këtu.

Llojet standarde të burimeve

Megjithëse mund të vendosni çfarëdo në burime, ka disa lloje standarde të caktuara:

• app_signature: Lloji MIME i aplikacionit, për të përshtatur skedarët e hapur, ekzekutimin, IPC, etj.
• app_name_catalog_entry: Pasi emri i aplikacionit është zakonisht në anglisht, këtu mund të specifikoni vendet ku ndodhen emrat e përkthyera, kështu që përdoruesit e gjuhëve të ndryshme do të shohin emrin e përkthyer të aplikacionit nëse dëshirojnë.
• app_version: pikërisht atë që menduat
• app_flags: tregon registrar si të trajtojë aplikacionin. Mendoj se ka diçka më shumë sesa duket në dukje. Për shembull, ka B_SINGLE_LAUNCH: që e bën sistemin të nisë një proces të ri të aplikacionit çdo herë, sipas kërkesës së përdoruesit (i njëjti parim përdoret për shumicën e aplikacioneve në Linux). Ka B_MULTIPLE_LAUNCH: që detyron të niset një proces për çdo skedar.Së fundi, ka B_EXCLUSIVE_LAUNCH: që e bën sistemin të niset vetëm një proces në të njëjtën kohë, pavarësisht nga sa herë e fillon përdoruesi (për shembull, kështu niset Firefox në Linux; mund të arrihet të njëjtin rezultat në aplikacionet Qt duke përdorur funksionin QtSingleApplication). Aplikacionet me B_EXCLUSIVE_LAUNCH njoftohen kur përdoruesi përpiqet t'i nisë ato përsëri: për shembull, marrin rrugën e skedarit që përdoruesi dëshiron të hapë me to.
• vector_icon: Ikona vektoriale e aplikacionit (Në BeOS nuk kishte ikona vektoriale, shumica e aplikacioneve kishin dy ikona rasterike në skedarët e ekzekutueshëm).

Sigurisht, është e mundur të shtoni burime me çdo ID dhe tipe të dëshiruara, pas së cilës t'i lexoni ato brenda aplikacionit ose në aplikacione të tjera duke përdorur klasën BResources. Por për fillim le të ndalemi te tema interesante e ikonave.

Ikona vektoriale në stilin Haiku

Natyrisht, jo vetëm Haiku ka zgjedhur formatin më të mirë të ikonave, në këtë pjesë situata me ambientet e punës Linux është larg nga 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ë një gjë të tillë, mund të ndihesh se çfarë është ky copë.

Sigurisht, ekziston scalable, që përmban, siç mund të kuptohet, ikona vektoriale. Pse ka diçka tjetër? Sepse rezultati i vizatimit të grafikës vektoriale në sizet e vogla mund të jetë më i dobët se idealja. Dëshira është të kemi variante të ndryshme, optimizuar për madhësi të ndryshme. Në ambientet e punës Linux, kjo arrihet duke shpërndarë ikonat me madhësi të ndryshme në 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

Kujdes: nuk ka nocion të versioneve të ndryshme të Firefox. Prandaj, nuk mund të përpunosh me hollësi situatën e pranisë së disa versioneve të aplikacionit në sistem.

Ikona të ndryshme të Firefox në versione të ndryshme. Deri tani nuk është e mundur të përpunosh këtë në Linux pa disa ndihma të ndryshme.

Mac OS X e përpunon pak më ndryshe:

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

Duket se ka një skedar firefox.icns në paketën Firefox.app, që përmban të gjitha madhësitë, kështu që versionet e ndryshme të një aplikacioni kanë ikona të ndryshme.
Shumë më mirë! Ikonat udhëtojnë së bashku me aplikacionin, të gjitha burimet në një skedar.

Të kthehemi te Haiku. Një zgjidhje mahnitëse, pa përjashtime. Sipas dokumentacionin:

Ka qenë zhvilluar një format i veçantë, i optimizuar shumë për madhësi të vogla dhe vizatime të shpejta, HVIF. Prandaj, ikonat tona janë kryesisht shumë më të vogla se në formatin raster ose në formatin e zakonshëm SVG.

Dhe ato janë vërtet optimizuar:

Madhësitë e ikonës në HVIF krahasuar me formate të tjera.

Dallimi është një rend të plotë!

Por magjia këtu nuk përfundon. I njëjti HVIF mund të tregojë nivele të ndryshme detajesh në varësi të madhësisë së paraqitjes, pavarësisht se është një format vektorial.

Nivele të ndryshme detajesh (LOD) në varësi të madhësisë së vizatimit

Tani për disavantazhet: nuk mund të marrësh SVG, ta hedhësh në ImageMagick dhe të përfundojë, duhet të kalosh disa cikle për të krijuar një ikonë në formatin HVIF. Këtu Shpjegime. Megjithatë, IconOMatic mund të importojë SVG mjaft të papërsosur; rreth 90% e detajeve të SVG importohen me një probabilitet, 10% e tjera do të duhet të rregullohen dhe ndryshohen manualisht. Mund të lexoni më shumë rreth asaj se si HVIF bën magjinë e tij. mund të në blog Lea Genson

Shtimi i ikonës në aplikacion

Tani mund të shtoj ikonën në paketën që është krijuar herën e kaluar, duke marrë parasysh të gjitha informacionet e marra.
Megjithatë, duke qenë se tani nuk kam shumë dëshirë të vizatoj ikonën time për "Përshëndetje, Botë" QtQuickApp — po 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ë se 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, kur ikona e re është kopjuar, ajo nuk shfaqet?

Ikona e kopjuar VICN:101:BEOS:ICONs nuk po përdoret si ikona për aplikacionin në menaxherin e skedarëve

Çfarë kam humbur?

Koment i zhvilluesit:

Duhet të krijoj një skedar rdef. me të gjitha burimet, pastaj të ekzekutoj komandën rc emri.rdef, kjo do të krijojë skedarin .rsrc. Më pas duhet të ekzekutoj komandën resattr -o emri_binarnik emri.rsrc. Të paktën, unë përdor komanda të tilla për të shtuar ikona në skenarët e mi.

Megjithatë, dëshiroja të krijoja një burim, e jo një atribut. Jam krejt i hutuar.

Shkallëzimi inteligjent me përdorimin e sistemit të skedarëve

Hapja dhe leximi i atributeve ELF punon ngadalë. Siç kam përmendur më parë, ikona shkruhet si burim në vetë skedarin. Ky mënyrë është më e sigurt, duke lejuar mbijetesën gjatë kopjimit në një sistem skedari tjetër. Megjithatë, pastaj ajo gjithashtu kopjohet në atributin e sistemit të skedarëve, p.sh. BEOS:ICON. Ky funksionon vetëm në disa sisteme skedarësh, p.sh. BFS. Ikonat e paraqitura nga sistemi (në Tracker dhe Deskbar) lexohen nga ky atribut i zgjeruar, sepse një zgjidhje e tillë funksionon shpejt. Në disa vende (atje ku shpejtësia nuk është e rëndësishme, p.sh. dritarja tipike "Informacione mbi programin") sistemi merr ikonën drejtpërdrejt nga burimi në skedar. Por kjo nuk është fundi. Mos harroni, në Mac, përdoruesit mund të zëvendësojnë ikonat e aplikacioneve, katalogëve, dokumenteve me të tyret, për shkak se në Mac ka mundësi të bëjnë këto "gjëra të rëndësishme", p.sh. zëvendësimi i ikonës së re të Slack me atë të mëparshmen. Haiku duhet të perceptohet si një burim (në skedar) si një ikonë origjinale, e cila është e furnizuar me aplikacionin, dhe atributi (në sistemin e skedarëve BFS) si një gjë që i lejon përdoruesit të bëjë ndryshime sipas dëshirës (megjithatë, një sugjerim, ndërfaqja grafike për të vendosur një ikonë të personalizuar mbi ikonën e paracaktuar ende nuk është realizuar).

Kontrolli i atributeve të sistemit të skedarëve

Me ndihmën e resaddr ka mundësinë të kontrolloni dhe vendosni atribute të 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.
(...)

Në thelb, ky është "gomari", i cili kryen transformimin nga burimet (e besueshme) në atributet (e shpejta) të sistemit të skedarëve. Dhe pasi sistemi parashikon marrjen e burimeve dhe kryen kopjimin automatikisht, unë nuk do të shqetësohem më për këtë.

Magjia e paketave hpkg

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

Me formatet tradicionale të paketave, kam qenë shumë i shqetësuar për një fakt të tillë: shkarkon një (paketë), por në sistem instalohet diçka tjetër (skedarët brenda paketës). Është mjaft e vështirë të menaxhosh skedarët (për shembull, t'i fshish ata), kur bëhet instalimi i një pakete në mënyrë tradicionale. Dhe gjithçka për shkak se përmbajtja e paketës shpërndahet në të gjithë sistemin e skedarëve, duke përfshirë vende ku një përdorues i zakonshëm mund të mos ketë akses për të shkruar. Kjo krijon një klasë të tërë programesh - menaxherët e paketave. Ndërsa transferimi i një softueri tashmë të instaluar, për shembull, në një makinë tjetër, një disk të lëvizshëm ose një server skedarësh bëhet edhe më e vështirë, madje edhe e pamundur. Në një sistem të zakonshëm të bazuar në Linux, mund të ekzistojnë lehtësisht nga disa qindra mijë deri në miliona skedarë të veçuar. Natyrisht, kjo është e brishtë dhe e ngadaltë, për shembull kur instalohet fillimisht sistemi, kur instalohen, azhurnohen dhe fshihen paketat e zakonshme, si dhe kur kopjohet një volum boot (partitioni rrënjor) në një medium tjetër.

Po punoj mbi projektin AppImage, një zgjidhje pjesshme për aplikacionet e përdoruesve të fundit. Ky është një format shpërndarjeje softuerike që mbledh një aplikacion dhe të gjitha varësitë e tij në një imazh të një sistemi skedarësh, i cili montohet gjatë nisjes së aplikacionit. Kjo e thjeshton ndjeshëm gjënë, pasi ImageMagick papritur shndërrohet në një skedar të vetme, i menaxhuar në menaxherin e skedarëve nga përdoruesit e zakonshëm. Qasja e propozuar funksionon vetëm për softuerin, siç pasqyrohet në emrin e projektit, dhe gjithashtu ka një grup të vetin lagështish, pasi ata që merren me shpërndarjen e softuerit për Linux gjithmonë e hedhin fajin mbi mua.

Të rikthehemi te Haiku. A arritëm të gjejmë një balancë optimale mes sistemeve tradicionale të paketave dhe shpërndarjes së softuerit në bazë të imazheve? Paketat e saj .hpkg janë në fakt imazhe të kompresuara të një sistemi skedarësh. Gjatë ngarkimit të sistemit, bërthama montohet të gjitha paketat e instaluara dhe aktive me mesazhe bërthamorë të përafërt si këto:

KERN: package_daemon [16042853:   924] paket aktiv: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] paket aktiv: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] paket aktiv: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] paket aktiv: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] paket aktiv: "llvm_libs-5.0.0-3-x86_64.hpkg"

Është e mrekullueshme, apo jo? Mbajeni fort, sepse më shumë vazhdon më vonë!

Ka një paket shumë speciale:

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

Ajo përmban një sistem operativ mjaft minimalistik, duke përfshirë bërthamën. Besoni ose jo, por edhe bërthama vetë nuk nxirret nga volumi i ngarkimit (particioni themelor), por ngarkohet me kujdes në vendin e tij nga paketa. .hpkg. Wow! E kam përmendur më parë se, sipas mendimit tim, pjesa e përgjithshme e sofistikimit dhe koherencës së Haiku është për shkak të faktit se e gjithë sistemi nga bërthama dhe hapësira themelore e përdoruesit, deri te menaxhimi i paketave dhe infrastruktura e ambientit të punës po zhvillohet nga një ekip i vetëm. Imagjinoni sa grupe dhe ekipe të ndryshme do të nevojiteshin për të vënë në funksion një gjë të tillë bazuar në Linux. [e imagjinoj projektin PuppyLinux, — shënimi i përkthyesit]. Pastaj imagjino se sa kohë do të kërkohet për ta implementuar këtë qasje në distribuime. Thuhet: merr një detyrë të thjeshtë, ndaje midis ekzekutorëve të ndryshëm, dhe do të komplikohet aq shumë sa që nuk do të jetë më e zgjidhshme. Haiku në këtë rast më hapi sytë. Mendoj se kjo është ajo që po ndodh aktualisht në Linux (Linux këtu është një term kolektiv që përfshin stack-un Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Rivendosja e sistemit duke përdorur hpkg

Sa shpesh ndodh situata e mëposhtme: përditësimi kalon me sukses, dhe më pas zbulohet se diçka nuk funksionon si duhet? Nëse përdorni menaxherë paketash standardë, është e vështirë të rikthehet gjendja e sistemit në momentin para instalimit të paketimeve të reja (p.sh., në rastin kur diçka shkon keq). Disa sisteme ofrojnë zgjidhje të drejtuara me kopje të sistemit të skedarëve, por ato janë mjaft të ngarkuara dhe përdoren shumë pak në të gjitha sistemet. Në Haiku, kjo zgjidhet përmes paketimeve. .hpkg. Çdo herë që ndryshohen paketat në sistem, paketat e vjetra nuk fshihen, por ruhen në sistem në nënkatalogje të këtij lloji /Haiku/system/packages/administrative/state-<...>/ përherë. Operacionet e papërfunduara ruajnë të dhënat e tyre në nënkatalogje /Haiku/system/packages/administrative/transaction-<...>/.

Përmbajtja /Haiku/system/packages/administrative. Katalogët "state..." përmbajnë skedarë teksti me emrat e paketave aktive, "transaction..." – vetë paketat.

"Gjatë gjendjes aktive të vjetër", domethënë lista .hpkg e paketave, aktive para ndryshimeve, shkruhet pas çdo operacioni në menaxherin e skedarëve në një skedë teksti /Haiku/system/packages/administrative/state-<...>/activated-packages. Në mënyrë të ngjashme, shkruhet gjendja e re "aktive" në një skedë teksti /Haiku/system/packages/administrative/activated-packages.

Katalogu /Haiku/system/packages/administrative/state-<...>/ përmban vetëm një skedë teksti me listën e paketave aktive të kësaj gjendjeje (nëse paketat instalohet pa u fshirë), dhe nëse paketat janë fshirë ose përditësuar – katalogu state përmban versionet e vjetra të paketave.

Gjatë ngarkimit të sistemit, vendoset mbi bazën e listës së paketave nëse do të aktivizohen (montohen) paketat. Kaq thjesht! Nëse gjatë ngarkimit diçka shkon keq – mund të tregoni menaxherit të ngarkimit të përdorë një listë tjetër, më të vjetër. Detyra është zgjidhur!

Menaxher i ngarkimit Haiku. Çdo pikë hyrjeje reflektosh gjendjen përkatëse "aktive"

Më pëlqen qasja me skedarë të thjeshtë teksti si listë të "gjendjes aktive", ku shkruhen emra të kuptueshëm. .hpkgKy është një kontrast i thellë me atë që është krijuar për makinat e jo për njerëzit një grumbull nga OSTree ose Flatpak në sistemin e skedave (në nivelin e njëjtë me Microsoft GUID).

Lista e paketave aktive për çdo moment

Të dhëna konfigurimi

Duket se në katalog /Haiku/system/packages/administrative/writable-files ndodhen skedarët e konfigurimit për paketat, por të disponueshme për shkronjë. Siç e mbani mend, .hpkg muntuar vetëm për lexim. Prandaj, këta skedarë duhet të kopjohen nga paketat përpara se të shkruhen. Kjo ka kuptim.

Integrimi i GUI për sistemin .hpkg

Tani le të shohim se si këto paketa të shkëlqyera .hpkg përballen me integrimin në ambientin e punës të përdoruesit (UX). Pas të gjithash, Haiku është bërë për përdorim personal. Personalish, kam vendosur një nivel të lartë duke krahasuar përvojën e përdoruesit me paketat .app në Macintosh me një përvojë të tillë në .hpkg. Nuk do ta krahasoja as situatën me ambientet e punës në Linux, sepse ajo është absolutisht e tmerrshme krahasuar me çfarëdo tjetër.

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

• Dua të shoh përmbajtjen e paketës .hpkg
• Dua të instaloj paketën
• Dua të fshij paketën
• Dua të fshij diçka që ka ardhur në sistem si një pjesë e paketës
• Dua të kopjoj diçka që ka ardhur në sistem si një pjesë e paketës
• Dua të shkarkoj të gjitha varësitë e paketës që nuk mund të jenë pjesë e çdo instalimi të Haiku (p.sh., kam një makinë fizikisht të izoluar pa qasje në internet).
• Dua të zhvendos paketat e mia (ose një pjesë të tyre) veçmas në një vend tjetër, të veçantë nga volumi i ngarkimit (particioni rrënjësor) (sepse, për shembull, kam mungesë hapësire atje).

Kjo duhet të mbulojë shumicën e rasteve themelore nga puna ime e përditshme. Le të fillojmë.

Kontrollimi i përmbajtjes së paketës

Në Mac thjesht klikoj me të djathtën mbi paketën për ta hapur dhe për të parë përmbajtjen në Finder. Pas të gjithash, është thjesht një katalog i maskuar! (E di që ka paketa .pkg për pjesën e sistemit që nuk është aplikacione, por përdoruesit e zakonshëm nuk ndihen zakonisht me to).

Në Haiku klikoj me të djathtën mbi paketën, pastaj klikoj mbi "Contents" për të parë atë që është brenda. Por këtu ka vetëm një listë skedarësh pa mundësi për t'i hapur ato me një klik të dyfishtë.
Do të ishte shumë më mirë nëse do të ishte një mënyrë (të përkohshme) për të montuar paketën .hpkg për të parë përmes menaxherit të skedave, dhe përdoruesi nuk do të duhet të shqetësohet për detajet e implementimit. (Nga ana tjetër, mund të hapet .hpkg paketa në Expander, i cili mund ta dekompresojë si çdo arkiv tjetër).

Në ndërfaqen HaikuDepot mund të shihni listën e skedave të paketës, por nuk ka mënyrë për të parë përmbajtjen, për shembull duke klikuar dy herë mbi README.md

Në këtë kategori, Mac fiton, por shtimi i funksionalitetit të nevojshëm për HaikuDepot nuk duhet të shkaktojë shumë vështirësi.

Instalimi i paketës përmes GUI

Në Mac, shumica e imazheve diskore .dmg përmbajnë paketa .app. Hapni imazhin diskor me një klik të dyfishtë, pastaj kopjoni paketën, për shembull, duke e tërhequr në /Applications Finder. Për mua, kjo është e natyrshme, por kam dëgjuar se disa fillestarë mund të mos munden ta përballojnë këtë. Në mënyrë të parazgjedhur, Apple "ofron" një katalog të përbashkët për sistemin /Applications (në NeXT ai ishte rrjetor, si dhe individual), por mund të vendosni lehtësisht aplikacionet tuaja në një server skedarësh ose në një nënkatalog $HOME/Applications, nëse ju pëlqen kështu.

Në Haiku, klikoni dy herë në paketë, pastaj klikoni mbi "Instalo", nuk ka asgjë më të thjeshtë. Më intereson se çfarë do të ndodhë nëse paketa ka varësi që janë të disponueshme në HaikuPorts, por ende nuk janë instaluar. Në Linux nuk dinë çfarë të bëjnë në këtë situatë, por zgjidhja është e qartë — të pyesin përdoruesin nëse duhet të shkarkojnë dhe instalojnë varësitë. Pikërisht atë që bën Haiku.

Kam shkarkuar paketën ‘sanity’ manualisht dhe e kam klikuar, menaxheri i paketave e di nga të marrë varësitë e saj (me kusht që repository-t të jenë tashmë të regjistruara në sistem). Jo çdo Distribucion Linux e bën këtë.

Një mënyrë tjetër është përdorimi i menaxherit të skedave, mjafton të tërheqni .hpkg paketën ose në /Haiku/system/packages për instalim të përbashkët (në mënyrë të parazgjedhur), ose në /Haiku/home/config/packages (për instalim individual; e paqartë me një klik të dyfishtë — ende më nervozon fjala “config” këtu, që për mua në këtë rast është sinonim me “settings”). E gjithë kjo ide e disa përdoruesve nuk është ende e disponueshme për Haiku (ndoshta për këtë shkak gjithçka është kaq e thjeshtë — nuk e di, ndoshta mundësitë shumëpërdoruese do ta komplikonin punën për mjedisin e punës të një kompjuteri personal).

Në këtë kategori fiton Haiku, sepse din të punojë jo vetëm me aplikacione, por edhe me programet sistemore.

Fshirja e paketës nga GUI

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

Në Haiku, së pari, duhet të gjeni se ku ndodhet paketa në sistem, sepse rrallë e vendosni atë aty ku duhet (gjithçka e bën sistemi). Zakonisht duhet të kërkoni në /Haiku/system/packages (në instalimin standard të sistemit), ose në /Haiku/home/config/packages (kam thënë tashmë se «config» është një emër i gabuar?). Pastaj aplikacioni vetëm tërhiqet në plehra, dhe kjo është e gjitha.
Lehtë! Megjithatë, unë nuk do ta thosha kështu. Ja se çfarë ndodh në të vërtetë:

Ja se çfarë ndodh nëse tërhiqni aplikacionin në plehra nga /Haiku/system/packages

Thjesht provoja të zhvendosja aplikacionin tim të djeshëm «Përshëndetje, Botë» në QtQuickApp në plehra. Nuk kam provuar të zhvendos një katalog sistemor, dhe për sa kohë që të gjitha paketat instalohen në katalogun sistemor - nuk është e mundur të hiqet një paketë .hpkg pa ndryshuar «përmbajtjen e tij». Një përdorues i zakonshëm do të friksohej, do të klikonte butonin «Anulo», i caktuar si i parazgjedhur.

Shpjegon mr. waddlesplash:

Ky mesazh është më shumë se 10 vjet. Më së shpejti ne duhet ta konfigurojmë atë në mënyrë që paralajmërimi të shfaqet vetëm kur zhvendoset vetë paketa. Përdoruesit e zakonshëm megjithatë nuk duhet të bëjnë kështu.

Mirë, ndoshta duhet ta bëj këtë duke përdorur HaikuDepot? Klikoj dy herë në paketë në /Haiku/system/packages, duke pritur që të shfaqet butoni «Çinstalo». Jo, ka (vetëm) «Instalo». «Çinstalo», ku je?

Për shuplakë provova të shoh se çfarë do të ndodhte nëse do të klikojë «Instalo» për një paketë që është tashmë e instaluar. Kështu e kemi:

Kjo është ajo që ndodh nëse provoni të instaloni një paketë që është tashmë e instaluar.

Menjëherë shfaqet:

Nëse klikoni «Apliko ndryshimet» në dritaren e mëparshme - do të ndodhë kështu

Mendoj se kjo është një defekt programor, ka një lidhje me aplikacionin tashmë. [autori nuk ofroi lidhjen, - shënim i përkthyesit]

Zgjidhja e shpejtë: Shtoni butonin «Çinstalo», nëse paketa tashmë është në /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 fshij.

Në këtë kategori fiton Mac. Por mund të imagjinoj se me konfigurimin e duhur, përvoja e përdoruesit në Haiku do të ishte më e mirë se në Mac. (Një nga zhvilluesit e vlerësoi kështu: «Më pak se një orë për të shtuar funksionalitetin e caktuar në HaikuDepot, nëse dini pak C++», ka vullnetarë?)

Heqja e diçkaje nga paketa

Le të provojmë të fshijmë aplikacionin vetë, jo paketën .hpkg, nga e cila ka ardhur (kam dyshime se ka ndonjë ndryshim për "vdekatarët e zakonshëm").

Në Mac, përdoruesi zakonisht punon me një skedar .dmg, nga vjen paketa e aplikacionit .app. Zakonisht, imazhet .dmg grumbullohen në katalogun e shkarkimeve, ndërsa paketat kopjohen nga përdoruesi në /Applications. Ka mendime se shumë përdorues nuk e dinë se çfarë po bëjnë, kjo Hipotezë mbështetet nga një ish-punonjës i Apple. (Një nga gjërat që nuk më pëlqen te Mac. Ndërsa, për shembull, me AppImage nuk ka ndarje mes aplikacionit dhe paketës ku ndodhet. E tërheq ikonën në kosha = dhe ja, është e gjithë puna. Lehtë!)

Në Haiku, gjithashtu ka një ndarje midis apps/ dhe packages/, kështu që kam dyshime se përdoruesit e kuptojnë më mirë nga kjo. Por çfarë ndodh nëse tërheq një aplikacion nga apps/ në kosh:

Këtu është se çfarë ndodh kur përpiqesh të heqësh një aplikacion të marrë nga skedari .hpkg

Teknikisht, është e saktë (sepse aplikacioni është vendosur në një sistem skedarësh që është vetëm për lexim, para së gjithash), por kjo nuk është shumë e dobishme për përdoruesin.

Zgjidhja e shpejtë: në vend të kësaj, ofroni të hiqni përmes GUI .hpkg

Për t'u argëtuar, provova të dublikoja aplikacionin duke shtypur Alt+D. Mora një mesazh "Nuk mund të lëvizë ose kopjoj objekte në volum të vetëm për lexim". Të gjitha për shkak se /system përveç /system/packages dhe /system/settings) është një pikë shkarkimi packagefs (mos harroni si shfaqet në daljen e df?). К сожалению, вывод команды mount nuk e qartëson situatën (siç u tha në një nga artikujt e mëparshëm), mountvolume nuk tregon atë që kërkoja (duke u dukur se paketat e montuara përmes loop-it .hpkg nuk llogariten si “volume”), si dhe harrova komandat alternative.

Në këtë kategori, askush nuk ka fituar përveç AppImage (por kjo, nëse jemi krejtësisht të sinqertë, është një mendim i njëanshëm). Megjithatë, mund të imagjinohet se pas rregullimit, përvoja e përdoruesit në Haiku do të ishte më e mirë se në Mac.

Vërejtje: duhet të zbulohet se çfarë do të thotë "volume" në lidhje me "particionin". Probabilisht ka të bëjë me raportin "folder" në "katalog": shumica e katalogëve shfaqen në menaxherin e skedave si dosje, por jo të gjitha (për shembull, paketat, të cilat trajtohen si skedarë). Ajo që sjell këto lehtësira do të më bënte nerd zyrtarisht?

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

Në Mac, thjesht tërheq paketën .app, dhe për shkak se varësitë brenda paketës - ato lëvizin së bashku.

Në Haiku, tërheq aplikacionin, por varësitë nuk trajtohen fare.

Zgjidhje e shpejtë: Le të propozojmë të tërhiqet paketa «`.hpkg në tërësi, së bashku me varësitë, nëse ekzistojnë.

Në këtë kategori, Mac fitojnë pa dilema. Të paktën për mua, adhuruesin e parimeve të tyre. Haiku duhet të kopjojë .hpkg në vend të aplikacionit, por sistemi nuk më ofron asnjë mundësi…

Shkarkimi i paketës me të gjitha varësitë e saj.

Jo çdo makinë është lidhur me rrjetin gjatë gjithë kohës. Përkundrazi, disa makina (po, shikoj te ju, Windows modern, Mac dhe Linux) e harrojnë këtë. Për mua, është e rëndësishme që mund të shkoj, për shembull, në një kafene interneti, të shkarkoj softuer në një pajisje të jashtme, ta vendos këtë pajisje në kompjuterin tim shtëpiak dhe të jem i sigurt se gjithçka do të funksionojë [dëmtuesi i guximshëm, të bësh diçka të tillë në Windows… — shënim i përkthyesit].

Si rezultat, më shpesh se gjithmonë, zakonisht kam varësi të paaftë në Windows dhe Linux.

Në Mac zakonisht është një skedar, gjithçka që duhet të bësh – shkarkosh. .dmg. Më së shpeshti ai nuk ka varësi, përveç atyre që ofrohen nga MacOS si rregull nëntë. Një përjashtim mund të përmendet aplikacione komplekse që kërkojnë mjedis përkatës, për shembull java.

Në Haiku shkarko paketën .hpkg për, të themi, të njëjtin aplikacion në java, mund të jetë e pamjaftueshme, pasi java mund të jetë ose të mos jetë në makinën e synuar. A ka ndonjë mënyrë për të shkarkuar të gjitha varësitë për këtë paketë .hpkg, përveç atyre që instalohet në Haiku si standart dhe, për pasojë, duhet të jenë në çdo sistem Haiku?

Në këtë kategori, Mac fiton me një përjashtim të vogël.

Komenton mr. waddlesplash:

Për të shkruar një program që mbledh të gjitha varësitë e aplikacionit në formën e një grupi paketash .hpkg për dikë që është njohur me brendinë e Haiku, mjafton rreth 15 minuta. Të shtosh mbështetje për këtë nuk është aq e vështirë, nëse ka një nevojë reale për të. Por për mua, kjo është një situatë e rrallë.

Mbajmë frymën deri në artikullin e ardhshëm në këtë cikël.

Shkëputja e paketave në një vend të veçantë

Siç e kam thënë më parë, dua të vendos paketat e mia. .hpkg (ose, ose pjesë të tyre) në një vend të veçantë, të ndarë nga vendosja e zakonshme në volumet e ngarkesës (ndarja kryesore). Në rastin e zakonshëm (nuk është aq tepricë teorike) arsyeja është — se vendi i lirë në disqet e mia (të ndërtuara) përfundimisht mbaron, pavarësisht sa të mëdhenj që janë ata. Dhe zakonisht lidh disqet e jashtme ose burimet rrjet, ku ndodhen aplikacionet e mia.

Në Mac Unë thjesht lëviz paketat .app në një disk të heqshëm ose në një katalog rrjeti në Finder, dhe kjo është gjithçka. Ende mund të hap aplikacionin me dy klikime si zakonisht e kam bërë me volumin e ngarkesës. Thjesht!

Në Haiku, siç më thanë, kjo mund të arrihet duke transferuar .hpkg paketat e mia në një disk të heqshëm ose në një katalog rrjeti, por pastaj duhet të përdor disa komanda të pa dokumentuara në konsolë për t'i montuar ato në sistem. Nuk e di se si ta bëj këtë, duke përdorur vetëm GUI.

Në këtë kategori fiton Mac.

Sipas zotit waddlesplash:

Këtu optimizimi është për përdorim të zakonshëm. Nëse do të ketë ndonjëherë kërkesë më të madhe se ajo e një përdoruesi, do ta realizojmë këtë. Në çdo rast ka mundësi realizimi nga palë të treta.

Për këtë do të flasim në artikullin tjetër.

Nëse flasim për katalogjet rrjet: do të ishte e shkëlqyer (mendoj festa LAN) të kishim aplikacione plotësisht të zbulueshme dhe të përdorshme rrjetore (për shembull, përmes Zeroconf), të cilat mund të kopjohen në kompjuterin lokal ose të nisen menjëherë nga rrjeti lokal. Natyrisht, zhvilluesit kanë mundësi për t'u hequr nga app_flags.

Raporti përfundimtar mbi integrimin e sistemit hpkg me GUI

Mendoj se sidomos për shkak të relativisht të reja integrimi .hpkg me GUI akoma lë për të dëshiruar. Mund të ketë disa gjëra që mund të përmirësohen në aspektin e UX…

Një gjë tjetër: Landsit e Diagnostikimit të Kernelit

Do të ishte e shkëlqyer në rast të panicit të kernelit të kisha mundësinë të futja komandat, për shembull syslog | grep usb. Epo, në Haiku kjo është e mundur falë Landsit të Diagnostikimit të Kernelit. Si mund të shohësh këtë magji në veprim, nëse gjithçka funksionon siç duhet pa rënë në panicin e kernelit? Lehtë, duke shtypur Alt+PrintScn+D (mnemonika Debug). Më vjen në mendje Tastiera e Programuesit, e cila lejonte zhvilluesit fillestarë të Macintosh të hynin në debugguer (nëse ishte e instaluar, sigurisht).

Përfundim

Po fillim më duket se sofistikimi i sistemit Haiku buron nga fakti se puna bëhet nga një ekip i vogël me fokus të qartë në ambientin e punës në dispozicionin e të gjitha niveleve të sistemit.
Një kontrast i mprehtë me botën Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, ku gjithçka është e copëtuar në pjesë kaq të vogla saqë abstraksioni është i mbështetur mbi abstraksion dhe po ashtu e ngre këtë me nickers.
Gjithashtu erdhi kuptimi se si sistemi .hpkg kombinon praktikat më të mira të menaxherëve tradicionalë të paketave, Snappy, Flatpak, AppImage, madje edhe btrfs, dhe i bashkon ato me parimin "punon thjesht" nga Mac.

Siç duket diçka është "ndërruar" në mendjen time dhe kuptova se si sistemi .hpkg është në gjendje të rikthehet, - thjesht duke e parë atë. Por kjo nuk është për mua, por për bukurinë dhe thjeshtësinë e sistemit. Shumë nga kjo është e mbushur me frymën e Mac-it origjinal.

Po, shikimi i faqeve në shfletues mund të jetë i ndërlikuar dhe të funksionojë si një kërpudhë, aplikacioneve mund t'i mungojnë (nuk ka Gtk, Electron - zhvilluesit kanë arritur në përfundimin se ato nuk kombinohen mirë me sofistikimin), përshpejtimi i videos dhe 3D mund të mungojë krejtësisht, por akoma më pëlqen ky sistem. Sepse këto gjëra mund të rregullohen dhe ato do të shfaqen vonë a herët. Kjo është vetëm një çështje kohe dhe ndoshta një copë syze të kuqe.

Nuk mund të ofroj ndihmë, por mendoj se që nga ky moment do të fillojë viti Haiku në desktop.

Probleme të rastësishme

A ka ndoshta tashmë aplikime, apo duhet të hap ato?

• BeScreenCapture duhet të ketë mundësinë për të eksportuar në GIF, si në Peek. Kjo mund të bëhet me ffmpeg, i cili është tashmë i pranishëm për Haiku. Aplikimi.
• Programi për krijimin e imazheve të ekranit nuk mund të bëjë një imazh të dritares modale, duke regjistruar në vend të kësaj tërë ekranin
• Nuk është e mundur të priten fotografitë e ekranit me mjetin e prerjes në WonderBrush, dhe më pas - të ruhet rezultati në një skedar
• Nuk më pëlqen shumë kursor në formë mace në Haiku, por mendoj se kjo është për shkak të ndjenjave nostalgjike të ngrohta. Kjo është sidomos e irritueshme kur përdorim mjetin e prerjes në Krita, pasi rezulton një prerje e pasaktë (shihni imazhet e ekranit me dialogët modalë në këtë artikull). Një kursor në formë kryqi do të ishte një kënaqësi. Aplikimi.

Provoja vetë! Sepse projekti Haiku ofron imazhe të ngarkimit nga DVD ose USB, që formohen çdo ditë. Për ta instaluar mjafton të shkarkoni imazhin dhe ta regjistroni në një flash drive duke përdorur Etcher

Keni ndonjë pyetje? Ju ftojmë në kanalin tonë në gjuhën ruse telegram-channel.

Pasqyrë e gabimeve: Si të gjuash veten në këmbë në C dhe C++. Kolleksioni i recetave për Haiku OS

Nga autori përkthimi: ky është artikulli i gjashtë në ciklin për Haiku.

Lista e artikujve: I pari I dyti I tretë I katërt I pestë

Burimi: habr.com