Diçka tjetër: paketat e aplikacioneve Haiku?

TL; DR: A mundet Haiku të marrë mbështetjen e duhur për paketat e aplikacioneve, siç janë drejtoritë e aplikacioneve (si .app në Mac) dhe/ose imazhet e aplikacionit (Linux AppImage)? Unë mendoj se kjo do të ishte një shtesë e denjë që është më e lehtë për t'u zbatuar saktë sesa sistemet e tjera pasi shumica e infrastrukturës është tashmë në vend.

Një javë më parë Zbulova Haikun, një sistem të mirë të papritur. Epo, meqenëse kam qenë prej kohësh i interesuar për drejtoritë dhe imazhet e aplikacioneve (të frymëzuar nga thjeshtësia e Macintosh-it), nuk është për t'u habitur që më erdhi një ide në mendje ...

Për ta kuptuar plotësisht, unë jam krijuesi dhe autori i AppImage, një format i shpërndarjes së aplikacionit Linux që synon thjeshtësinë e Mac dhe u jep kontroll të plotë autorëve të aplikacioneve dhe përdoruesve përfundimtarë (nëse doni të dini më shumë, shihni wiki и dokumentacionin).

Po sikur të bëjmë një AppImage për Haikun?

Le të mendojmë pak, thjesht teorikisht: çfarë duhet bërë për të marrë AppImage, apo diçka e ngjashme, në Haiku? Nuk është e nevojshme të krijosh diçka tani, sepse sistemi që ekziston tashmë në Haiku funksionon mahnitshëm, por një eksperiment imagjinar do të ishte mirë. Ai gjithashtu demonstron sofistikimin e Haiku-t, krahasuar me mjediset desktop Linux, ku gjëra të tilla janë tmerrësisht të vështira (kam të drejtë të them kështu: kam 10 vjet që po luftoj me korrigjimin e gabimeve).

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

Së pari, çfarë është një AppImage? Ky është një sistem për lëshimin e aplikacioneve të palëve të treta (për shembull, Ultimaker Cure), duke lejuar që aplikacionet të lëshohen kur dhe si duan: nuk ka nevojë të dihen specifikat e shpërndarjeve të ndryshme, të ndërtohen politika ose të ndërtohet infrastrukturë, nuk nevojitet mbështetje për mirëmbajtjen dhe nuk u tregojnë përdoruesve se çfarë (jo) mund të instalojnë në kompjuterët e tyre. AppImage duhet të kuptohet si diçka e ngjashme me një paketë Mac në format .app brenda imazhit të diskut .dmg. Dallimi kryesor është se aplikacionet nuk kopjohen, por mbeten brenda AppImage përgjithmonë, pothuajse njësoj si paketat Haiku. .hpkg montuar dhe kurrë nuk është instaluar në kuptimin e zakonshëm.

Gjatë rrjedhës së më shumë se 10 viteve të ekzistencës, AppImage ka fituar një tërheqje dhe popullaritet: vetë Linus Torvalds e miratoi publikisht atë dhe projektet e zakonshme (për shembull, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) e kanë miratuar atë si mënyrën kryesore. për të shpërndarë ndërtime të vazhdueshme ose gjatë natës, duke mos ndërhyrë në aplikacionet e instaluara ose të çinstaluara të përdoruesve. Sidoqoftë, mjediset dhe shpërndarjet e desktopit të Linux-it më shpesh ende i përmbahen modelit tradicional, të centralizuar të shpërndarjes të bazuar në mirëmbajtësi dhe/ose promovojnë biznesin e tyre të ndërmarrjes dhe/ose programet inxhinierike bazuar në Flatpak (RedHat, Fedora, GNOME) dhe i gjallë (Canonical, Ubuntu). Vjen në mënyrë qesharake.

Si funksionon e gjitha

• Çdo AppImage përmban 2 pjesë: një ELF të vogël me dy klikim (të ashtuquajturat. runtime.c), e ndjekur nga një imazh i sistemit të skedarëve Kungull.

• Sistemi i skedarëve SquashFS përmban ngarkesën e aplikacionit dhe gjithçka që nevojitet për ta ekzekutuar atë, e cila në mendjen e duhur nuk mund të konsiderohet pjesë e instalimit të paracaktuar për çdo sistem objektiv mjaft të fundit (shpërndarja Linux). Ai gjithashtu përmban meta të dhëna, si emri i aplikacionit, ikonat, llojet MIME, etj., etj.

• Kur ekzekutohet nga përdoruesi, koha e ekzekutimit përdor FUSE dhe squashfuse për të montuar sistemin e skedarëve dhe më pas trajton ekzekutimin e një pike hyrëse (aka AppRun) brenda AppImage-it të montuar.
  Sistemi i skedarëve çmontohet pas përfundimit të procesit.

Gjithçka duket e thjeshtë.

Dhe këto gjëra komplikojnë gjithçka:

• Me një shumëllojshmëri të tillë të shpërndarjeve Linux, asgjë "me mendjen e duhur" nuk mund të quhet "pjesë e instalimit të paracaktuar për çdo sistem të ri të synuar". Ne punojmë rreth kësaj çështjeje duke ndërtuar listë përjashtuese, duke ju lejuar të përcaktoni se çfarë do të paketohet në AppImage dhe çfarë do të duhet të merret diku tjetër. Në të njëjtën kohë, ndonjëherë na mungon, përkundër faktit se, në përgjithësi, gjithçka funksionon shkëlqyeshëm. Për këtë arsye, ne rekomandojmë që krijuesit e paketave të testojnë AppImages në të gjitha sistemet e synuara (shpërndarjet).
• Ngarkesat e aplikacionit duhet të jenë të zhvendosshme nëpër sistemin e skedarëve. Fatkeqësisht, shumë aplikacione kanë shtigje absolute të koduara, për shembull, në burime /usr/share. Kjo duhet të rregullohet disi. Përveç kësaj, ju ose duhet të eksportoni LD_LIBRARY_PATH, ose rregulloni rpath në mënyrë që ngarkuesi të mund të gjejë bibliotekat përkatëse. Metoda e parë ka të metat e saj (të cilat kapërcehen në mënyra komplekse), dhe e dyta është thjesht e rëndë.
• Gracka më e madhe UX për përdoruesit është ajo vendos bitin e ekzekutueshëm Skedari AppImage pas shkarkimit. Besoni apo jo, kjo është një pengesë e vërtetë për disa. Nevoja për të vendosur bitin e ekzekutueshmërisë është e rëndë edhe për përdoruesit me përvojë. Si zgjidhje, ne sugjeruam instalimin e një shërbimi të vogël që monitoron skedarët AppImage dhe cakton bitin e tyre të ekzekutueshmërisë. Në formën e tij të pastër, nuk është zgjidhja më e mirë, pasi nuk do të funksionojë jashtë kutisë. Shpërndarjet Linux nuk e ofrojnë këtë shërbim, prandaj, përdoruesit kanë një përvojë të keqe jashtë kutisë.
• Përdoruesit e Linux presin që një aplikacion i ri të ketë një ikonë në menunë e fillimit. Nuk mund t'i thuash sistemit: "Shiko, ka një aplikacion të ri, le të punojmë." Në vend të kësaj, sipas specifikimeve XDG, duhet të kopjoni skedarin .desktop në vendin e duhur në /usr për një instalim në të gjithë sistemin, ose në $HOME për individuale. Ikonat e madhësive të caktuara, sipas specifikimeve XDG, duhet të vendosen në vende të caktuara usr ose $HOME, dhe më pas ekzekutoni komandat në mjedisin e punës për të përditësuar cache-in e ikonave, ose shpresoni që menaxheri i mjedisit të punës do ta kuptojë dhe do të zbulojë automatikisht gjithçka. E njëjta gjë me llojet MIME. Si zgjidhje, propozohet përdorimi i të njëjtit shërbim, i cili përveç vendosjes së flamurit të ekzekutueshmërisë, nëse ka ikona, etj. në AppImage, kopjoni ato nga AppImage në vendet e duhura sipas XDG. Kur fshihet ose zhvendoset, shërbimi pritet të pastrojë gjithçka. Sigurisht, ka dallime në sjelljen e çdo mjedisi pune, në formatet e skedarëve grafikë, madhësitë e tyre, vendndodhjet e ruajtjes dhe metodat për përditësimin e cache-ve, gjë që krijon një problem. Me pak fjalë, kjo metodë është një patericë.
• Nëse sa më sipër nuk mjafton, nuk ka ende asnjë ikonë AppImage në menaxherin e skedarëve. Bota Linux nuk ka vendosur ende të zbatojë elficon (megjithë diskutim и zbatimi), kështu që është e pamundur të futni ikonën drejtpërdrejt në aplikacion. Pra, rezulton se aplikacionet në menaxherin e skedarëve nuk kanë ikonat e tyre (pa dallim, AppImage ose diçka tjetër), ato janë vetëm në menunë e fillimit. Si zgjidhje, ne po përdorim miniaturë, një mekanizëm që fillimisht u krijua për të lejuar menaxherët e desktopit të shfaqin imazhe paraprake të fotografive të skedarëve grafikë si ikona të tyre. Rrjedhimisht, shërbimi për vendosjen e bitit të ekzekutueshmërisë funksionon gjithashtu si një "miniatorizues", duke krijuar dhe shkruar miniaturë ikonash në vendet e duhura /usr и $HOME. Ky shërbim gjithashtu kryen pastrim nëse AppImage fshihet ose zhvendoset. Për shkak të faktit se çdo menaxher desktopi sillet paksa ndryshe, për shembull, në çfarë formatesh pranon ikona, në cilat madhësi ose vende, e gjithë kjo është vërtet e dhimbshme.
• Aplikacioni thjesht rrëzohet gjatë ekzekutimit nëse ndodhin gabime (për shembull, ekziston një bibliotekë që nuk është pjesë e sistemit bazë dhe nuk ofrohet në AppImage), dhe askush nuk i tregon përdoruesit në GUI se çfarë saktësisht po ndodh. Ne filluam ta kapërcejmë këtë duke përdorur njoftimet në desktop, që do të thotë se ne duhet të kapim gabimet nga linja e komandës, t'i konvertojmë ato në mesazhe të kuptuara nga përdoruesi, të cilat më pas duhet të shfaqen në desktop. Dhe sigurisht, çdo mjedis desktop i trajton ato pak më ndryshe.
• Për momentin (shtator 2019 - shënimi i përkthyesit) nuk kam gjetur një mënyrë të thjeshtë për t'i treguar sistemit se skedari 1.png duhet të hapet duke përdorur Krita, dhe 2.png - duke përdorur GIMP.

Vendndodhja e ruajtjes për specifikimet ndër-desktop të përdorura në GNOME, KDE и Xfce është freedesktop.org

Arritja e nivelit të sofistikimit të endur thellë në mjedisin e punës Haiku është e vështirë, nëse jo e pamundur, për shkak të specifikimeve XDG nga freedesktop.org për ndër-desktop, si dhe implementime të menaxherëve të desktopit bazuar në këto specifika. Si shembull, mund të citojmë një ikonë të Firefox-it në të gjithë sistemin: me sa duket, autorët e XDG as që menduan se një përdorues mund të kishte të instaluar disa versione të të njëjtit aplikacion.

Ikonat për versione të ndryshme të Firefox-it

Po pyesja veten se çfarë mund të mësonte bota Linux nga Mac OS X për të shmangur prishjen e integrimit të sistemit. Nëse keni kohë dhe jeni në këtë, sigurohuni që të lexoni atë që tha Arnaud Gurdol, një nga inxhinierët e parë të Mac OS X:

Ne donim ta bënim instalimin e aplikacionit aq të lehtë sa zvarritja e ikonës së aplikacionit nga diku (server, disku i jashtëm) në diskun e kompjuterit tuaj. Për ta bërë këtë, paketa e aplikacionit ruan të gjithë informacionin, duke përfshirë ikonat, versionin, llojin e skedarit që përpunohet, llojin e skemave URL që sistemi duhet të dijë për të përpunuar aplikacionin. Kjo përfshin gjithashtu informacionin për "ruajtjen qendrore" 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': drejtoritë e aplikacioneve të sistemit dhe përdoruesve, dhe disa të tjera automatikisht nëse përdoruesi lundron te Finder në direktorinë që përmban aplikacionin. Në praktikë kjo funksionoi shumë mirë.

https://youtu.be/qQsnqWJ8D2c
Sesioni 2000 i Apple WWDC 144 - Mac OS X: aplikacionet e paketimit dhe printimi i dokumenteve.

Nuk ka asgjë si kjo infrastrukturë në desktopët Linux, kështu që ne po kërkojmë zgjidhje rreth kufizimeve strukturore në projektin AppImage.

A po vjen Haiku në shpëtim?

Dhe një gjë tjetër: platformat Linux si bazë e mjediseve të desktopit priren të jenë aq të nënspecifikuara sa që shumë gjëra që janë mjaft të thjeshta në një sistem të qëndrueshëm të plotë janë të fragmentuara dhe komplekse në mënyrë frustruese në Linux. I kushtova një raport të tërë çështjeve që lidhen me platformën Linux për mjediset e desktopit (zhvilluesit e ditur konfirmuan se gjithçka do të mbetet kështu për një kohë shumë të gjatë).

Raporti im mbi problemet e mjediseve të desktopit Linux në 2018

Edhe Linus Torvalds pranoi se fragmentimi ishte arsyeja pse ideja e hapësirës së punës dështoi.

Më vjen mirë të shoh Haikun!

Haiku e bën gjithçka çuditërisht të thjeshtë

Ndërsa qasja naive për "transportimin" e AppImage në Haiku është thjesht të përpiqesh të ndërtosh (kryesisht runtime.c dhe shërbim) komponentët e tij (që madje mund të jetë e mundur!), kjo nuk do të sjellë shumë përfitime për Haiku. Sepse në fakt, shumica e këtyre problemeve zgjidhen në Haiku dhe janë konceptualisht të shëndosha. Haiku ofron saktësisht blloqet e ndërtimit të infrastrukturës së sistemit që unë kam kërkuar në mjediset e desktopit Linux për kaq shumë kohë dhe nuk mund të besoja se nuk ishin aty. Gjegjësisht:

Besoni apo jo, kjo është diçka që shumë përdorues të Linux nuk mund ta kapërcejnë. Në Haiku gjithçka bëhet automatikisht!

• Skedarët ELF që nuk kanë një bit ekzekutueshmërie e marrin automatikisht një të tillë kur klikohen dy herë në menaxherin e skedarëve.
• Aplikacionet mund të kenë burime të integruara, të tilla si ikona, që shfaqen në menaxherin e skedarëve. Nuk ka nevojë të kopjoni një grup imazhesh në drejtori të veçanta me ikona, dhe për këtë arsye nuk ka nevojë t'i pastroni ato pas fshirjes ose zhvendosjes së aplikacionit.
• Ekziston një bazë të dhënash për lidhjen e aplikacioneve me dokumente, nuk ka nevojë të kopjoni ndonjë skedar për këtë.
• Në direktorinë lib/ pranë skedarit të ekzekutueshëm, bibliotekat kërkohen si parazgjedhje.
• Nuk ka shpërndarje të shumta dhe mjedise desktop; çfarëdo që funksionon, funksionon kudo.
• Nuk ka asnjë modul të veçantë për të ekzekutuar që është i ndryshëm nga drejtoria e aplikacioneve.
• Aplikacionet nuk kanë shtigje absolute të integruara për burimet e tyre; ato kanë funksione të veçanta për përcaktimin e vendndodhjes në kohën e ekzekutimit.
• Ideja e imazheve të sistemit të skedarëve të ngjeshur është prezantuar: kjo është çdo paketë hpkg. Të gjithë ata janë montuar nga kerneli.
• Çdo skedar hapet nga aplikacioni që e ka krijuar atë, përveç nëse specifikoni në mënyrë të qartë ndryshe. Sa e lezetshme është kjo!

Dy skedarë png. Vini re ikonat e ndryshme që tregojnë se ato do të hapen nga aplikacione të ndryshme kur klikohen dy herë. Gjithashtu vini re menunë rënëse "Hap me:" ku përdoruesi mund të zgjedhë një aplikacion individual. Sa e thjeshtë!

Duket sikur shumë nga paterica dhe zgjidhjet e kërkuara nga AppImage në Linux bëhen të panevojshme në Haiku, i cili ka thjeshtësinë dhe sofistikimin në thelbin e tij që e bën atë të trajtojë shumicën e nevojave tona.

A ka nevojë Haiku në fund të fundit për paketat e aplikacioneve?

Kjo çon në një pyetje të madhe. Nëse do të ishte më e lehtë për të krijuar një sistem si AppImage në Haiku sesa në Linux, a ia vlente të bëhej? Apo Haiku, me sistemin e tij të paketave hpkg, e ka eliminuar efektivisht nevojën për të zhvilluar një ide të tillë? Epo, për t'iu përgjigjur duhet të shohim motivimin pas ekzistencës së AppImages.

Perspektiva e përdoruesit

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

• Unë dua të instaloj një aplikacion pa kërkuar një fjalëkalim administratori (root). Nuk ka koncept administratori në Haiku, përdoruesi ka kontroll të plotë pasi është një sistem personal! (Në parim, ju mund ta imagjinoni këtë në modalitetin me shumë lojtarë, shpresoj që zhvilluesit ta mbajnë të thjeshtë)
• Unë dua të marr versionet më të fundit dhe më të mira të aplikacioneve, pa pritur që ato të shfaqen në shpërndarjen time (më shpesh kjo do të thotë "kurrë", të paktën nëse nuk përditësoj të gjithë sistemin operativ). Në Haiku kjo "zgjidhet" me lëshime lundruese. Kjo do të thotë se është e mundur të merrni versionet më të fundit dhe më të mira të aplikacioneve, por për ta bërë këtë ju duhet të përditësoni vazhdimisht pjesën tjetër të sistemit, duke e kthyer atë në mënyrë efektive në një "objektiv në lëvizje".
• Unë dua disa versione të të njëjtit aplikacion krah për krah, pasi nuk ka asnjë mënyrë për të ditur se çfarë është prishur në versionin e fundit, ose, të themi, unë, si një zhvillues ueb, duhet të testoj punën time nën versione të ndryshme të shfletuesit. Haiku zgjidh problemin e parë, por jo të dytin. Përditësimet janë rikthyer, por vetëm për të gjithë sistemin; është e pamundur (me sa di unë) të ekzekutohen, për shembull, disa versione të WebPositive ose LibreOffice në të njëjtën kohë.

Një nga zhvilluesit shkruan:

Në thelb arsyetimi është ky: rasti i përdorimit është aq i rrallë saqë optimizimi për të nuk ka kuptim; Trajtimi i tij si një rast i veçantë në HaikuPorts duket më se i pranueshëm.

• Më duhet t'i mbaj aplikacionet aty ku më pëlqejnë, jo në diskun tim të fillimit. Shpesh më mbaron hapësira në disk, kështu që më duhet të lidh një disk të jashtëm ose drejtori rrjeti për të ruajtur aplikacionet (të gjitha versionet që kam shkarkuar). Nëse lidh një disk të tillë, më duhet që aplikacionet të hapen duke klikuar dy herë. Haiku ruan versionet e vjetra të paketave, por nuk di si t'i zhvendos në një disk të jashtëm ose si t'i nis aplikacionet nga atje më vonë.

Komenti i zhvilluesit:

Teknikisht, kjo tashmë është e mundur me komandën montuese. Sigurisht, ne do të bëjmë një GUI për këtë sapo të kemi mjaft përdorues të interesuar.

• Nuk kam nevojë për miliona skedarë të shpërndarë nëpër sistemin e skedarëve që nuk mund t'i menaxhoj manualisht. Unë dua një skedar për aplikacion që mund ta shkarkoj, lëviz, fshij lehtësisht. Në Haiku ky problem zgjidhet duke përdorur paketat .hpkg, të cilat transferojnë, për shembull, python, nga mijëra skedarë në një. Por nëse ka, për shembull, Scribus duke përdorur python, atëherë duhet të merrem me të paktën dy skedarë. Dhe unë duhet të kujdesem që të mbaj versione të tyre që funksionojnë me njëra-tjetrën.

Versione të shumta të AppImages që funksionojnë krah për krah në të njëjtin Linux

Perspektiva e një zhvilluesi të aplikacionit

Le të shohim nga këndvështrimi i një zhvilluesi të aplikacionit:

• Unë dua të kontrolloj të gjithë përvojën e përdoruesit. Nuk dua të varem nga një sistem operativ për të më thënë se kur dhe si duhet të lëshoj aplikacionet. Haiku i lejon zhvilluesit të punojnë me depot e tyre hpkg, por kjo do të thotë se përdoruesit do të duhet t'i konfigurojnë ato manualisht, gjë që e bën idenë "më pak tërheqëse".
• Unë kam një faqe shkarkimi në faqen time ku shpërndaj .exe për Windows, .dmg për Mac dhe .AppImage për Linux. Apo ndoshta dua të fitoj para nga aksesi në këtë faqe, çdo gjë është e mundur? Çfarë duhet të vendos atje për Haikun? Dosja është e mjaftueshme .hpkg me varësi vetëm nga HaikuPorts
• Softueri im kërkon versione specifike të softuerëve të tjerë. Për shembull, dihet se Krita kërkon një version të korrigjuar të Qt, ose Qt që është përshtatur mirë me një version specifik të Krita, të paktën derisa arna të shtyhen përsëri në Qt. Ju mund të paketoni Qt-në tuaj për aplikacionin tuaj në një paketë .hpkg, por me shumë mundësi kjo nuk është e mirëpritur.

Faqja e rregullt e shkarkimit të aplikacionit. Çfarë duhet të postoj këtu për Haikun?

Paketat e testamenteve (që ekzistojnë si drejtori aplikacionesh si AppDir ose .app Stil Apple) dhe/ose imazhe (në formën e AppImages të modifikuara shumë ose .dmg nga Apple) aplikacionet një shtesë e dobishme në mjedisin e desktopit Haiku? Apo do të hollojë të gjithë pamjen dhe do të çojë në fragmentim, dhe për këtë arsye do të shtojë kompleksitetin? Unë jam i grisur: nga njëra anë, bukuria dhe sofistikimi i Haikut bazohet në faktin se zakonisht ka një mënyrë për të bërë diçka, dhe jo shumë. Nga ana tjetër, pjesa më e madhe e infrastrukturës për katalogët dhe/ose paketat e aplikacioneve është tashmë në vend, kështu që sistemi thërret që disa përqindje të mbetura të vendosen në vend.

Sipas zhvilluesit Zoti. spërkatje

Në Linux ata (katalogë dhe komplete aplikimi, - përafërsisht. përkthyes) janë me shumë mundësi një zgjidhje teknike për problemet sistemike. Në Haiku ne preferojmë të zgjidhim thjesht problemet e sistemit.

Çfarë mendoni ju?

Perpara se te pergjigjesh...

Prisni, le të bëjmë një kontroll të shpejtë të realitetit: në fakt drejtoritë e aplikacioneve - tashmë pjesë e Haikut:

Drejtoritë e aplikacioneve ekzistojnë tashmë në Haiku, por nuk mbështeten ende në menaxherin e skedarëve

Ata thjesht nuk mbështeten aq mirë sa, të themi, Macintosh Finder. Sa bukur do të ishte nëse drejtoria QtCreator do të kishte një emër dhe ikonë "QtCreator" në këndin e sipërm majtas, duke e nisur aplikacionin kur klikohet dy herë?

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

Jeni i sigurt që mund të përdorni aplikacionet tuaja të vjetra dhjetëvjeçare sot kur të gjitha dyqanet e aplikacioneve dhe depot e shpërndarjes i kanë harruar ato dhe varësitë e tyre? A jeni i sigurt se do të jeni ende në gjendje të hyni në punën tuaj aktuale në të ardhmen?

A ka tashmë një përgjigje nga Haiku, apo mund të ndihmojnë katalogët dhe paketat e aplikacioneve këtu? Mendoj se munden.

Sipas z. spërkatje me valë:

Po, ne kemi përgjigjen e pyetjes: ne thjesht do t'i mbështesim këto aplikacione për aq kohë sa të jetë e nevojshme derisa dikush të mund të lexojë formatet e tyre të skedarëve në mënyrën e duhur ose të sigurojë funksionalitet një-për-një. Angazhimi ynë për të mbështetur aplikacionet BeOS R5 në Haiku është dëshmi e kësaj...

Kjo është e sigurt!

Çfarë veprimi duhet të marrë Haiku?

Unë mund të imagjinoj bashkëjetesën paqësore të hpkg, drejtorive dhe imazheve të aplikacioneve:

• Përdorimi i softuerit të sistemit .hpkg
• Për softuerin më të përdorur (veçanërisht ata që duhet të planifikojnë lëshimet e përsëritura), përdorni .hpkg (afërsisht 80% e të gjitha rasteve)
• Disa të instaluara nëpërmjet .hpkg, aplikacionet do të përfitojnë nga lëvizja në një infrastrukturë të drejtorisë së aplikacionit (p.sh. QtCreator): ato do të shpërndahen si .hpkg, si më parë.

Zoti. waddlesplash shkruan:

Nëse gjithçka që ju nevojitet është të shikoni aplikacionet në /system/apps, në vend të kësaj ne duhet t'i bëjmë drejtoritë në Deskbar më të menaxhueshme për përdoruesit, pasi /system/apps nuk synohet të hapet dhe shikohet rregullisht nga përdoruesit (ndryshe nga MacOS). Për situata të tilla, Haiku ka një paradigmë tjetër, por ky opsion është, në teori, i pranueshëm.

• Haiku merr infrastrukturën për ekzekutimin e imazheve të aplikacioneve, ndërtimet e programeve gjatë natës, të vazhdueshme dhe testuese, si dhe për rastet kur përdoruesi dëshiron ta "ngrijë atë në kohë", për softuer privat dhe të brendshëm, dhe raste të tjera të përdorimit të veçantë (rreth 20% nga të gjitha). Këto imazhe përmbajnë skedarët e nevojshëm për të ekzekutuar aplikacionin .hpkg, montuar nga sistemi, dhe pasi aplikimi të përfundojë - çmontohet. (Ndoshta një menaxher skedari mund të vendosë skedarë .hpkg në imazhet e aplikacionit, automatikisht ose me kërkesë të përdoruesit - mirë, si kur tërhiqni një aplikacion në një drejtori rrjeti ose një disk të jashtëm. Është thjesht një këngë! Ose më mirë, poezi - haiku.) Nga ana tjetër, përdoruesi mund të dëshirojë të instalojë përmbajtjen e imazhit në formën e skedarëve.hpkg, pas së cilës ato do të përditësohen dhe përpunohen në të njëjtën mënyrë sikur të ishin instaluar përmes HaikuDepot... Duhet të bëjmë stuhi idesh).

Citim nga z. spërkatje me valë:

Ekzekutimi i aplikacioneve nga disqet e jashtme ose drejtoritë e rrjetit mund të jetë i dobishëm. Dhe shtimi i aftësisë për të konfiguruar më shumë "zona" për pkgman do të ishte padyshim një veçori e bukur.

Një sistem i tillë do të përfitonte nga hpkg, drejtoritë dhe imazhet e aplikacioneve. Ata janë të mirë individualisht, por së bashku do të bëhen të pathyeshëm.

Përfundim

Haiku ka një kornizë që ofron një përvojë të thjeshtë dhe të sofistikuar të përdoruesit për PC, dhe shkon shumë përtej asaj që ofrohet zakonisht për PC Linux. Sistemi i paketave .hpkg është një shembull i tillë, por pjesa tjetër e sistemit është gjithashtu e mbushur me sofistikim. Megjithatë, Haiku do të përfitonte nga mbështetja e duhur e dosjeve dhe imazhit të aplikacionit. Sa më mirë për ta bërë këtë ia vlen të diskutohet me njerëz që e njohin Haikun, filozofinë dhe arkitekturën e tij shumë më mirë se unë. Në fund të fundit, unë kam përdorur Haiku për pak më shumë se një javë. Megjithatë, besoj se projektuesit, zhvilluesit dhe arkitektët e Haikut do të përfitojnë nga kjo perspektivë e re. Së paku, do të isha i lumtur të isha "partneri i tyre sparring". Unë kam mbi 10 vjet përvojë praktike me katalogët dhe paketat e aplikacioneve Linux, dhe do të doja të gjeja një përdorim për to në Haiku, për të cilin mendoj se janë një përshtatje e përsosur. Zgjidhjet e mundshme që kam propozuar nuk janë aspak të vetmet e sakta për problemet që kam përshkruar dhe nëse ekipi i Haiku vendos të gjejë të tjera, më elegante, unë jam i gjithi për këtë. Në thelb, unë tashmë jam duke menduar për idenë se si të krijoj një sistem hpkg edhe më e mahnitshme pa ndryshuar mënyrën se si funksionon. Rezulton se ekipi Haiku kishte menduar për paketat e aplikacioneve për një kohë të gjatë gjatë zbatimit të një sistemi të menaxhimit të paketave, por për fat të keq (mendoj) ideja u "vjetërua". Ndoshta është koha për ta ringjallur atë?

Provojeni vetë! Në fund të fundit, projekti Haiku ofron imazhe për nisje nga DVD ose USB, të krijuara i përditshëm.
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 tetë dhe i fundit në serinë për Haikun.

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

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

A ka kuptim të portosh sistemin hpkg në Linux?

• Po

• Jo

• E zbatuar tashmë, do të shkruaj në komente

20 përdorues votuan. 5 përdorues abstenuan.

Burimi: www.habr.com