🥇Disa gjëra të tjera: paketat e aplikacioneve të Haiku?

TL;DR: a mund të marrë Haiku mbështetje të duhur për paketat e aplikacioneve, si për shembull katalogët e aplikacioneve (si në .app Mac) dhe/ose imazhet e aplikacioneve (Linux AppImage)? Më duket se do të ishte një shtesë e vlefshme që është më e lehtë për t'u vendosur sesa në sisteme të tjera, për shkak se shumica e infrastrukturës është tashmë aty.

Një javë më parë e kam zbuluar Haiku, një sistem befasues mirë. Dhe pasi që kam qenë prej kohësh i interesuar për katalogët dhe imazhet e aplikacioneve (të frymëzuara nga thjeshtësia e Macintosh), nuk është e çuditshme që më erdhi në mendje ideja...

Për një kuptim të plotë: unë jam krijuesi dhe autori i AppImage, një format shpërndarjeje për aplikacionet Linux, i orientuar drejt thjeshtësisë së Mac dhe që ofron kontroll të plotë për autorët e aplikacioneve dhe përdoruesit përfundimtarë (nëse dëshiron të dish më shumë — shiko wiki dhe dokumentacion).

Çfarë nëse bëjmë AppImage për Haiku?

Le të spekulojmë pak, thjesht teorikisht: çfarë duhet bërë për të marrë AppImage, ose diçka e ngjashme, në Haiku? Nuk është e nevojshme të krijojmë diçka pikërisht tani, sepse sistemi i cili është tashmë në Haiku funksionon mahnitshëm, ndërsa eksperimentimi i imagjinuar do të ishte i këndshëm. Plus, ilustron sofistikimin e Haiku, krahasuar me mjediset e punës Linux, ku gjëra të tilla janë rënduese (kam të drejtë ta them këtë: 10 vjet e kam kaluar duke u përpjekur me debug-imin).

Në Macintosh System 1, çdo aplikacion ishte një skedar i veçantë, "i menaxhuar" në Finder. Duke përdorur AppImage përpiqem të rishkrijoj këtë eksperiencë përdoruesi në Linux.

Së pari, çfarë është AppImage? Është një sistem për lëshimin e aplikacioneve nga zhvilluesit e tretë (p.sh. Ultimaker Cura), që lejon lëshimin e aplikacioneve, kur dhe si dëshirojnë: nuk është nevojshme të dihet për veçoritë e shpërndarjeve të ndryshme, politikat e ndërtimit ose infrastrukturën e ndërtimit, nuk nevojitet mbështetje e asistencës, dhe ata nuk i thonë përdoruesve se çfarë (nuk) duhet të instalojnë në kompjuterët e tyre. AppImage duhet të kuptohet si diçka e ngjashme me një paketë për Mac në formatin .app brenda imazhit të diskut .dmg. Diferenca kryesore është se aplikacionet nuk kopjohen, por qëndrojnë brenda AppImage gjithmonë, pak si paketat Haiku .hpkg montohet, dhe asnjëherë nuk instalohen në kuptimin e zakonshëm.

AppImage ka më shumë se 10 vjet ekzistence ka fituar një tërheqje dhe popullaritet të caktuar: vetë Linus Torvalds e ka miratuar publikisht atë, dhe projektet e njohura (për shembull, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) e kanë pranuar atë si mënyrën kryesore për shpërndarjen e ndërtimve të vazhdueshme ose natën, pa penguar aplikacionet e instaluara ose të pa instaluara nga përdoruesit. Megjithatë, mjediset e punës dhe shpërndarjet Linux shpesh vazhdojnë të mbahen pas modelit tradicional, të centralizuar të shpërndarjes mbi bazën e paketave dhe/ose promovojnë programet e tyre të korporatave dhe/ose inxhinierike, Flatpak (RedHat, Fedora, GNOME) dhe Snappy (Canonical, Ubuntu). Arrin në të qeshur.

Si funksionon gjithçka

Çdo AppImage përmban në vete 2 pjesë: një ekzekutues të vogël me dy klikime ELF (i njohur si runtime.c), me një imazh të mëpasshëm të sistemit të skedarëve SquashFS.

Sistemi i skedarëve SquashFS përmban ndihmën si një aplikacion dhe gjithçka e nevojshme për ta drejtuar atë, e cila në mendje të shëndoshë nuk mund të konsiderohet si pjesë e instalimit të paracaktuar për çdo sistem të qëllimshëm të mjaftueshëm të modernizuar (shpërndarjes Linux). Ajo gjithashtu përmban metadata, për shembull emrin e aplikacionit, ikona, lloje MIME dhe të tjera.

Kur përdoruesi e nis, runtime përdor FUSE dhe squashfuse për të montuar sistemin e skedarëve, pas së cilës përpunon fillimin e një pikë kyçe (të njohur si AppRun) brenda AppImage të montuar.
Sistemi i skedarëve çmontohet pas përfundimit të procesit.

Duket gjithçka e thjeshtë.

Por këto gjëra e komplikojojnë gjithçka:

me këtë larmi shpërndarjesh Linux asgjë «në mendje të shëndoshë» nuk mund të quhet «pjesë e instalimit të paracaktuar për çdo sistem të qëllimshëm të freskët». Ne e kalojmë këtë problem nëpërmjet ndërtimit të excludelist, që përcakton se çfarë do të paketizohet në AppImage dhe çfarë duhet të merret diku tjetër. Megjithatë, ndonjëherë gabojmë, ndonëse në përgjithësi gjithçka funksionon mjaft mirë. Për këtë arsye, ne rekomandojmë krijuesve të paketave që të kontrollojnë AppImages në të gjitha sistemet e synuara (shpërndarjet).
Aplikacionet si ndihmë duhet të jenë të transportueshme në sistemin e skedarëve. Fatkeqësisht, në shumë aplikacione janë dhënë rrugë absolute, për shembull, për burimet në /usr/share. Kjo duhet siç duhet të korrektohet. Përveç kësaj, duhet ose të eksportoni LD_LIBRARY_PATH, ose të korrigjoni rpath në mënyrë që ngarkuesi të mund të gjejë bibliotekat e lidhura. Metoda e parë ka disavantazhe të saj (të cilat kapërcehen me mënyra të komplikuara), ndërsa e dyta është thjesht e ngarkuar.
Krahu më i madh i UX për përdoruesit është se duhet të vendosni bitin e ekzekutimit në skedarin AppImage pas shkarkimit. Doni të besoni, doni jo, por për disa njerëz është një pengesë e vërtetë. Nevoja për të vendosur bitin e ekzekutimit është e ngarkuar edhe për përdoruesit me përvojë. Si një zgjidhje alternative, ne propozuam instalim të një shërbimi të vogël që ndjek skedarët AppImage dhe vendos bitin e ekzekutimit për ta. Në vetë formën e saj, nuk është zgjidhja më e mirë, pasi nuk do të funksionojë “nga kutia”. Distribucioni Linux nuk ofron këtë shërbim, prandaj për përdoruesit “nga kutia” gjërat janë të këqija.
Përdoruesit e Linux presin që një aplikacion i ri të ketë një ikonë në menynë e nisjes. Sistemit nuk i thua: “Shiko, aty është aplikacioni i ri, le të punojmë”. Në vend të kësaj, sipas specifikimit XDG, duhet të kopjoni skedarin .desktop në vendin e duhur në /usr për instalim sistemor, ose në $HOME për individuale. Ikonat e disa madhësive, sipas specifikimit XDG, duhet të vendosen në vende të caktuara në usr или $HOME, pas të cilave duhet të ekzekutoni komandat në mjedisin e punës për të azhurnuar caches e ikonave, ose të shpresoni që menaxherët e mjedisit të punës do ta kapin dhe do ta zbulojnë automatikisht të gjitha. Njësoj për llojet MIME. Si një zgjidhje alternative, propozohet të përdoret i njëjti shërbim, i cili përveç vendosjes së bitit të ekzekutimit do të kopjojë, nëse ka ikona etj. në AppImage, ato në vendet e nevojshme sipas XDG. Kur të fshihen ose të lëvizin, shërbimi pritet t'i pastronte të gjitha. Sigurisht, ka ndryshime në sjelljen e çdo mjedisi të punës, në formatet e skedarëve grafikë, dimensionet e tyre, vendet e ruajtjes dhe mënyrat e azhurnimit të caches, të cilat krijojnë problemin. Në përmbledhje, ky është një zgjidhje e thjeshtë.
Nëse ato lart janë të pamjaftueshme, menaxheri i skedarëve gjithashtu nuk ka një ikonë AppImage. Në botën e Linux-it ende nuk është arritur një vendim për të implementuar elficon (pavarësisht nga diskutimi dhe implementation), kështu që është e pamundur të merren ikonat direkt në aplikacion. Kështu që, aplikacionet në menaxherin e skedarëve nuk kanë ikona të tyre (nuk ka rëndësi, AppImage apo diçka tjetër), ato ekzistojnë vetëm në menunë e lançimit. Si një zgjidhje anësore, ne përdorim miniaturat — një mekanizëm që fillimisht është zhvilluar që menaxherët e desktopit të mund të tregojnë imazhe të zvogëluara për parashikim të skedarëve grafikë si ikona të tyre. Prandaj, shërbimi për vendosjen e paqes së ekzekutueshmërisë funksionon gjithashtu si një /usr dhe $HOMEminiaturizues
duke krijuar dhe regjistruar miniaturat e ikonave në vendet përkatëse. Po ashtu, ky shërbim kryen pastrimin nëse AppImage eliminohet ose lëvizet. Duke qenë se çdo menaxher desktopi sillet paksa ndryshe, për shembull, në cilat formate pranon ikonat, në cilat madhësi apo vende, kjo është vërtet shumë e dhimbshme. Aplikacioni thjesht dështon gjatë ekzekutimit nëse ndodhin gabime (për shembull, ka një bibliotekë që nuk është pjesë e sistemit themelor dhe nuk është e përfshirë në AppImage), dhe askush nuk i thotë përdoruesit në GUI se çfarë po ndodh në të vërtetë. Ne filluam ta anashkalojmë këtë duke përdorur njoftimet
në desktop, prandaj na duhet të kapim gabimet nga komandimi, t'i kthejmë ato në mesazhe të kuptueshme për përdoruesin, të cilat duhet gjithashtu të shfaqen në desktop. Dhe sigurisht, çdo ambient pune i trajton ato paksa ndryshe. 1.png Më aktualisht (shtator 2019, - shënimi i përkthyesit) nuk kam gjetur një rrugë të thjeshtë për t'i thënë sistemit se skedari 2.png duhet të hapet me Krita, dhe

— me GIMP. GNOME, KDE dhe Xfce Vendi i ruajtjes së specifikimeve cross-desktop, të përdorura në

është freedesktop.org Arritja e një niveli rafinimi, thellësisht e ndërlidhur me ambientin e punës Haiku, është e vështirë, nëse nuk është e pamundur, për shkak të specifikimeve XDG nga freedesktop.org

për cross-desktop, si dhe realizimeve të menaxherëve të desktopit të bazuar në këto specifikime. Si shembull mund të përmendim një ikonë sistemsh për Firefox: duket se autorët e XDG nuk kanë menduar se përdoruesi mund të ketë instaluar disa versione të të njëjtit aplikacion.

Më interesonte se çfarë mund të mësonte bota Linux nga Mac OS X, për të mos dështuar në integrimin sistemor. Nëse keni kohë dhe merremi me diçka të tillë — patjetër lexoni çfarë tha Arno Gurdol, një nga inxhinierët e parë të Mac OS X:

Donim që instalimi i aplikacionit të ishte po aq i thjeshtë sa tërheqja e ikonës së aplikacionit nga ndonjë vend (server, disk i jashtëm) në diskun e kompjuterit tuaj. Për këtë, në paketën e aplikacionit ruhet gjithë informacioni, duke përfshirë ikonat, versionin, llojin e dosjes që përpunon, llojin e skemës së URL, që sistemi duhet ta dijë për të përpunuar aplikacionin. Këtu përfshihet informacioni për 'ruajtjen e centralizuar' në bazën e të dhënave të Shërbimeve të Ikonave dhe Shërbimeve të Nisjes. Për të mbështetur performancën, aplikacionet 'zbulohen' në disa 'vende të njohura': në katalogun sistemor dhe atë të përdoruesit të Aplikacioneve, si dhe në disa të tjera automatikisht, nëse përdoruesi kalon në Finder në katalogun që përmban aplikacionin. Në praktikë, kjo ka funksionuar shumë mirë.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesioni 144 — Mac OS X: paketimi i aplikacioneve dhe printimi i dokumenteve.

Asgjë e ngjashme nga kjo infrastrukturë nuk është në ambientet e punës Linux, prandaj po kërkojmë anashkalime rreth kufizimeve strukturore në projektin AppImage.

A po nxitohet Haiku për të ndihmuar?

Dhe më shumë: platformat Linux si baza për ambientet e punës, zakonisht janë nën-specifikuar deri në atë pikë sa shumë gjëra, që janë shumë të thjeshta në një sistem të konsoliduar me një grup të plotë, zhgënjejnë me fragmentimin dhe kompleksitetin në Linux. I kam kushtuar një tërë referat shqetësimeve që lidhen me platformën Linux për ambientet e punës (zhvilluesit e njohur e konfirmuan: gjithçka do të mbetet kështu për një kohë të gjatë).

Referati im për problemet e ambientit të punës Linux në 2018

Madje Linus Torvalds e pranoi se pikërisht për shkak të fragmentimit, ideja e ambientit të punës nuk arriti.

Është kënaqësi të shoh Haiku!

Me Haiku, gjithçka bëhet mahnitshëm e thjeshtë

Megjithëse qasja naive për "transportimin" e AppImage në Haiku përfshin thjesht përpjekjen për të ndërtuar (në thelb runtime.c dhe shërbimin) komponentët e tij (gjë që mund të jetë edhe e mundur!), kjo nuk do të sjellë ndonjë dobi për Haiku. Sepse në të vërtetë shumica e këtyre problemeve janë zgjidhur në Haiku dhe janë konceptualisht të arsyeshme. Haiku ofron pikërisht ato katrorë për infrastrukturën sistemore që unë kam kërkuar kaq gjatë në ambientet e punës në Linux dhe nuk mund ta besoj se nuk ishin atje. Konkretisht:

Besoni ose jo, por kjo nuk mund të bëhet nga shumë përdorues të Linux. Në Haiku gjithçka ndodh automatikisht!

Skedarët ELF, që nuk kanë bitin e ekzekutueshmërisë, e marrin atë automatikisht me një çift goditje në menaxherin e skedareve.
Aplikacionet mund të kenë burime të integruara, për shembull ikona, të cilat shfaqen në menaxherin e skedareve. Nuk është e nevojshme të kopjoni një sërë imazhesh në katalogë të veçantë të ikonave, dhe për pasojë, nuk është e nevojshme t'i pastroni ato pas fshirjes ose lëvizjes së aplikacionit.
Ekziston një bazë të dhënash për lidhjen e aplikacioneve me dokumentet, nuk është e nevojshme të kopjoni ndonjë skedar për këtë.
Në katalogun lib/ përreth skedarit ekzekutues, bibliotekat kërkohen si parazgjedhje.
Nuk ka shumë distribucione dhe ambiente punë, gjithçka që funksionon — funksionon kudo.
Nuk ekziston një moduli të veçantë për ekzekutimin që do të ndryshonte nga katalogu i Aplikacioneve.
Në aplikacione nuk ka rrugë absolute të integruara për burimet e tyre, ka funksione të veçanta për të përcaktuar vendndodhjen gjatë ekzekutimit.
Ideja e imazheve të kompresuara të sistemeve të skedarëve është e integruar: kjo është çdo paketë hpkg. Të gjitha ato montohen nga bërthama.
Çdo skedar hapet nga aplikacioni që e krijoi, nëse nuk tregohet qartë ndonjë gjë tjetër. Sa e mrekullueshme është kjo!

Dy skedarë png. Vini re ikonat e ndryshme, që tregojnë se ato do të hapen nga aplikacione të ndryshme me një çift goditje. Po ashtu, vini re menun e rënë "Hap me:", ku përdoruesi mund të zgjedhë një aplikacion të veçantë. Sa e thjeshtë!

Duket se shumë nga këto aludime dhe anashkalime, të nevojshme për AppImage në Linux, bëhen të panevojshme në Haiku, e cila ka në thelb thjeshtësinë dhe sofistikimin, duke e bërë atë të përballojë shumicën e nevojave tona.

A nevojiten paketat e aplikacioneve për Haiku, në fund të fundit?

Kjo na çon te një pyetje e madhe. Nëse do të ishte më e lehtë të krijohej një sistem i ngjashëm me AppImage në Haiku sesa në Linux, a do të ishte e arsyeshme të merreshim me të? Ose, ndoshta, Haiku me sistemin e saj të pakove hpkg faktikisht eliminon nevojën për zhvillimin e një ideje të tillë? Epo, për të përgjigjur, është e nevojshme të shohim motivimin pas ekzistencës së AppImages.

Një perspektivë nga përdoruesi

Le të shohim për përdoruesin tonë përfundimtar:

Dua të instaloj një aplikacion pa kërkesën e fjalëkalimit të administratorit (root). Në Haiku nuk ka një koncept administratori, përdoruesi ka kontroll të plotë, pasi është një sistem personal! (Në të vërtetë, mund ta imagjinojmë këtë edhe në mënyrë shumëpërdoruesi, shpresoj se zhvilluesit do ta ruajnë thjeshtësinë)
Dua të marr versionet më të fundit dhe më të mira të aplikacioneve, pa pritur që ato të shfaqen në shpërndarjen time (shpeshherë kjo do të thotë "kurrë", të paktën, nëse nuk përditësoj të gjithë operativin). Në Haiku kjo është "zgjidhur" me lëshimet flotante. Kjo do të thotë se ka mundësinë për të marrë versionet më të fundit dhe më të mira të aplikacioneve, por për këtë duhet të përditësoj vazhdimisht edhe pjesën tjetër të sistemit, duke e kthyer atë në një "cak lëvizës"..
Më pëlqen të kem disa versione të njëjtit aplikacion afër, sepse nuk është e mundur të di se çfarë është prishur në versionin më të fundit, ose, për shembull, si zhvillues web, duhet të verifikoj punën time nën versione të ndryshme të shfletuesit. Në Haiku është zgjidhur problemi i parë, por jo ai i dytë. Përditësimet bëhen tërhiqen, por vetëm për sistemin në tërësi, nuk është e mundur (sipas dijenisë sime) të ekzekutohen, për shembull, disa versione të WebPositive ose LibreOffice në të njëjtën kohë.

Një nga zhvilluesit shkruan:

Në thelb, justifikimi është se skenari i përdorimit është kaq i rrallë, saqë optimizimi për të nuk ka kuptim; përpunimi i tij si rast i veçantë në HaikuPorts duket më se i pranueshëm.

Më duhet të ruaj aplikacionet aty ku më pëlqen, jo në disqet e ngarkesës. Në disqet e mia shpesh me mbaron vendi, kështu që duhet të lidhem me një disk të jashtëm ose një katalog rrjeti për ruajtjen e aplikacioneve (të gjitha versionet që kam shkarkuar). Nëse lidhem me një disk të tillë — duhet që aplikacionet të nisin me një dyfishtë klikim. Haiku ruan versionet e vjetra të pakove, por nuk e di si t'i transferoj ato në një disk të jashtëm, si dhe si të ftoj më pas aplikacionet nga aty.

Koment i zhvilluesit:

Teknikisht, kjo është tashmë e mundur me komandën mount. Sigurisht, ne do të krijojmë një GUI për këtë, sapo të mbledhim mjaft përdorues të interesuar.

Nuk kam nevojë për miliona skedarë të shpërndara në sistemin e skedave, të cilët nuk mund t'i menaxhoj manualisht. Dua një skedar për aplikacion, që mund ta shkarkoj, e lëviz, e fshij lehtësisht. Në Haiku, ky problem zgjidhet me ndihmën e paketave .hpkg, të cilat transferojnë, për shembull python, nga mijëra skedarë në një. Por nëse ka, për shembull, Scribus, që përdor python, atëherë duhet të merrem me të paktën dy skedarë. Dhe duhet të kujdesem që të ruaj versionet që punojnë së bashku.

Versionet e shumta të AppImages, të ekzekutuara paralelisht në një Linux

Një perspektivë nga ana e zhvilluesve të aplikacioneve

Le të shohim nga perspektiva e zhvilluesit të aplikacioneve:

Dua të menaxhoj përvojën e përdoruesit në mënyrë të plotë. Nuk dua të varet nga sistemi operativ që do të më tregojë kur dhe si duhet të publikoj aplikacione. Në Haiku, zhvilluesit mund të punojnë me repozitorët e tyre hpkg, por kjo do të thotë se përdoruesit do të duhet t'i konfigurojnë ato manualisht, gjë që e bën këtë ide "më pak tërheqëse".
Kam një faqe shkarkimi në faqen time të internetit, ku shpërndaj .exe për Windows, .dmg për Mac dhe .AppImage për Linux. Ndoshta, do të doja të monetizoja qasje në këtë faqe, çfarë duhet të vendos aty për Haiku? Mjafton një skedar .hpkg me varësitë vetëm nga HaikuPorts
Softueri im ka nevojë për versionet specifike të softuerëve të tjerë. Për shembull, dihet se për Krita nevojitet një version i rregulluar i Qt, ose Qt i konfiguruar saktësisht për një version të caktuar të Krita, të paktën deri sa rregullimet të kthehen në Qt. Mund të paketosh Qt tëndin për aplikacionin në paketë .hpkg, por me siguri, kjo nuk pritet mirë.

Një faqe e zakonshme shkarkimi për aplikacionin. Çfarë duhet të vendos këtu për Haiku?

A do të jenë paketat (që ekzistojnë si katalogë aplikacionesh, si AppDir ose .app në stilin e Apple) dhe/ose imazhet (në formën e AppImages të modifikuara ndjeshëm apo .dmg Aplikacione të Apple) janë një shtesë e dobishme për ambientin e punës Haiku? Ose kjo do ta prishte tërësinë dhe do të shkaktonte fragmentim, duke shtuar kështu kompleksitet? Unë jam në dilemë: nga njëra anë, bukuria dhe delikatesa e Haiku bazohet në faktin që zakonisht ka një mënyrë të vetme për të bërë diçka, dhe jo shumë. Nga ana tjetër, një pjesë e madhe e infrastrukturës për katalogët dhe/ose paketat aplikative është tashmë në vend, prandaj sistemi kërkon që edhe disa përqindje të mbetura të vendosen në vendet e tyre.

Sipas zhvilluesit, mr. waddlesplash

Në Linux ata (katalogët dhe paketat aplikative, – shënimi i përkthyesit) ndoshta janë një zgjidhje teknike për problemet sistemore. Në Haiku ne preferojmë thjesht të zgjidhim problemet sistemore.

Çfarë mendoni ju?

Para se të përgjigjeni…

Pritni, le të bëjmë një kontroll të shpejtë të realitetit: realisht katalogët e aplikacioneve – tashmë janë pjesë e Haiku:

Katalogët e aplikacioneve tashmë ekzistojnë në Haiku, por aktualisht nuk mbështeten në menaxherin e skedarëve.

Thjesht nuk mbështeten aq mirë sa, për shembull, në Finder-in e Macintosh. Sa bukur do të ishte nëse katalogu QtCreator do të kishte në këndin e sipërm të majtë emrin dhe ikonën "QtCreator", duke nisur aplikacionin me dy klikime?

Pak më herët unë tashmë pyeta:

A jeni të sigurt se do të nisni aplikacionet tuaja të para një dekade sot, kur të gjitha dyqanet e aplikacioneve dhe depozitë të shpërndarjeve t'i harrojnë ato dhe varësitë e tyre? A jeni të sigurt se do të keni akoma akses në punën tuaj aktuale në të ardhmen?

A ka ndonjë përgjigje nga Haiku, ose a do të mund të ndihmojnë katalogët dhe paketat aplikative këtu? Mendoj se po.

Sipas zotit waddlesplash:

Po, ne kemi një përgjigje për pyetjen: ne thjesht do të vazhdojmë të mbështesim këto aplikacione aq sa të jetë e nevojshme, derisa dikush të mund të lexojë formatet e tyre të skedave në mënyrën e duhur ose të sigurojë funksionalitetin një me një. Dedikimi ynë për të mbështetur punën e aplikacioneve BeOS R5 në Haiku është një dëshmi e drejtpërdrejtë për këtë…

Kjo është e sigurt!

Cili është plani i veprimit që duhet të marrë Haiku?

Mund të imagjinoj një koegzistencë paqeje mes hpkg, katalogëve dhe imazheve të aplikacioneve:

Programi sistemor përdor .hpkg
Për programe mjaft të përdorura (veçanërisht për ato që duhet të planifikohet publikimi i lëvizshëm) përdoret .hpkg (rreth 80% të rasteve)
Disa, të instaluara përmes .hpkg, aplikacionet do të fitojnë kur kalojnë në infrastrukturën me katalogë aplikacionesh (p.sh. QtCreator): ato do të shpërndahen në formën e .hpkg, ashtu si më parë.

mr. waddlesplash shkruan:

Nëse gjithçka që nevojitet është – shikimi i aplikacioneve në /system/apps, në vend të kësaj, duhet bërë katalogët në Deskbar më të menaxhueshëm për përdoruesit, pasi /system/apps nuk është menduar që përdoruesit ta hapin dhe ta shikojnë atë me rregull (ndryshe nga MacOS). Për situata të tilla, Haiku ka një paradigëm të ndryshme, por ky opsion, teorikisht, është i pranueshëm.

Haiku merr infrastrukturën për ekzekutimin e imazheve të aplikacioneve, ndërtimeve të natës, ndërtimeve të vazhdueshme dhe testeve të softuerit, si dhe për rastet kur përdoruesi dëshiron ta « ngrirë në kohë », për softuerin privat dhe të brendshëm, dhe raste të tjera të veçanta (rreth 20% të të gjithëve). Këto imazhe përmbajnë skedarët e nevojshëm për ekzekutimin e aplikacionit .hpkg, të montueshme nga sistemi, dhe pas përfundimit të aplikacionit – të demontueshme. (Ndoshta menaxheri i skedarëve mund të vendosë skedarët .hpkg në imazhet e aplikacioneve, automatikisht ose me kërkesë nga përdoruesi – si kur tërhiqni aplikacionin në një katalog rrjeti ose një disk të jashtëm. Kjo është thjesht një këngë! Më saktësisht një poezi – haiku.) Nga ana tjetër, përdoruesi mund të dëshirojë të instalohet përmbajtja e imazhit si skedarë.hpkg, pas së cilës ato do të përditësohen dhe përpunohen pikërisht siç do të ishin instaluar përmes HaikuDepot… Duhet bërë një brain storm).

Citim nga mr. waddlesplash:

Ekzekutimi i aplikacioneve nga disqet e jashtme ose katalogët rrjetë potencialisht mund të jetë i dobishëm. Dhe shtimi i mundësisë për të konfiguruar më shumë « zona » për pkgman për sigurisht do të ishte një funksion i mirë.

Një sistem i tillë do të shfrytëzojë përparësitë e hpkg, katalogëve dhe imazheve të aplikacioneve. Ato janë të mira dhe veçmas, por së bashku do të bëhen të pa mundur.

Përfundim

Për Haiku ekziston një infrastrukturë që ofron një ndërfaqe përdoruesi të thjeshtë dhe të sofistikuar për PC, dhe që e tejkalon shumë atë që zakonisht ofrohet për PC-të në Linux. Sistemi i paketave .hpkg — një nga këto shembuj, por pjesët e tjera të sistemit janë gjithashtu të mbushura me sofistikim. Megjithatë, mbështetje më e mirë për katalogët dhe imazhet e aplikacioneve të Haiku do të ishte e dobishme. Si ta bëjmë këtë më mirë — vlen të diskutohet me ata që e njohin Haiku, filozofinë dhe arkitekturën e saj shumë më mirë se unë. Në fund të fundit, unë e përdor Haiku që pak më shumë se një javë. Por megjithatë, besoj se ky perspektivë e freskët do të jetë e dobishme për dizajnerët, zhvilluesit dhe arkitektët e Haiku. Të paktën, do të jem i lumtur të jem një "partner sparring" për ta. Kam më shumë se 10 vjet përvojë praktike me katalogët dhe paketat e aplikacioneve për Linux, dhe do të doja t'i gjeja një përdorim për Haiku, për konceptin e të cilit, sipas mendimit tim, ata i përshtaten perfekt. Zgjidhjet e propozuara nga unë nuk janë aspak të vetmet të sakta për problemet që kam përshkruar, dhe nëse ekipi i Haiku vendos të gjejë zgjidhje më delikate — unë vetëm e përkrah atë. Në parim, kam filluar të mendoj për idenë se si të bëj sistemin hpkg edhe më të mahnitshëm, pa ndryshuar mënyrën si funksionon. Duket se ekipi i Haiku ka menduar për paketat e aplikacioneve gjatë implementimit të sistemit të menaxhimit të paketave, por fatkeqësisht, (më duket) ideja është lënë pas dore. Ndoshta ka ardhur koha ta ringjallim atë?

Provoja vetë! Sepse projekti Haiku ofron imazhe të ngarkimit nga DVD ose USB, që formohen çdo ditë.
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: kjo është artikulli i tetë dhe përfundimtar i ciklit rreth Haiku.

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

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.