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

TL;DR: a mund të marrë Haiku mbështetje të denjë për paketat e aplikacioneve, për shembull katalogët e aplikacioneve (siç .app në Mac) dhe/ose imazhe të aplikacioneve (Linux AppImage)? Më duket se do të ishte një shtesë e denjë, e cila do të ishte më e lehtë për t'u zbatuar sesa në sistemet e tjera, pasi pjesa më e madhe e infrastrukture është tashmë e pranishme.

Një javë më parë zbuloj Haiku, një sistem befasues i mirë. Dhe, duke qenë se prej kohësh jam i interesuar për katalogët dhe imazhet e aplikacioneve (të frymëzuara nga thjeshtësia e Macintosh), nuk është çudi që më erdhi ideja...

Për ta kuptuar plotësisht: unë jam krijuesi dhe autori i AppImage, një formati shpërndarjeje për aplikacionet Linux, i orientuar për thjeshtësinë e Mac dhe që ofron kontroll të plotë për autorët e aplikacioneve dhe përdoruesit e fundit (nëse doni të dini më shumë — shihni. wiki dhe dokumentacioni).

Çfarë nëse krijojmë AppImage për Haiku?

Le të shqyrtojmë pak, pastaj teorikisht, çfarë duhet bërë për të marrë AppImage, ose diçka të ngjashme në Haiku? Nuk është e nevojshme të krijosh diçka pikërisht tani, sepse sistemi që tashmë ekziston në Haiku funksionon mahnitshëm, dhe një eksperiment imagjinar do të ishte gjithashtu i mirë. Për më tepër, ai tregon rafinimin e Haiku, krahasuar me mjediset e punës Linux, ku gjëra të tilla janë jashtëzakonisht të vështira (kam të drejtë të flas kështu: 10 vjet e kam kaluar me debugimin).

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

Së pari, çfarë është AppImage? Është një sistem për lëshimin e aplikacioneve nga zhvillues të jashtëm (për shembull, Ultimaker Cura), që lejon lëshimin e aplikacioneve kur dhe si dëshirojnë: nuk është e nevojshme të dihet veçanitë e shpërndarjeve të ndryshme, politikave të ndërtimit ose infrastrukturës së ndërtimit, nuk ka nevojë për mbështetje nga shoqëruesit, dhe ata nuk tregojnë për përdoruesit se çfarë mund (ose jo) të instalohen në kompjuterët e tyre. AppImage duhet të kuptohet si diçka, e ngjashme me paketën për Mac në formatin .app në brendësi të imazhit të diskut .dmg. Dallimi kryesor është se aplikacionet nuk kopjohen, por mbeten në brendësi të AppImage gjithmonë, më pak si paketat e Haiku .hpkg instalohen dhe kurrë nuk vendosen në kuptimin e zakonshëm.

AppImage ka fituar disa tërheqje dhe popullaritet në më shumë se 10 vjet ekzistencë: vetë Linus Torvalds e ka miratuar atë publikisht, dhe projektet e njohura (p.sh., LibreOffice, Krita, Inkscape, Scribus, ImageMagick) e kanë pranuar atë si mënyrën kryesore për shpërndarjen e ndërtimeve të vazhdueshme ose natën, pa penguar aplikacionet e instaluara ose jo të instaluara të përdoruesve. Megjithatë, mjediset e punës dhe shpërndarjet e Linux shpesh ende mbajnë të ngjitur modelin tradicional, qendror të shpërndarjes të bazuar në shoqëruesit dhe/ose promovojnë programet e tyre të biznesit dhe/ose inxhinierisë. Flatpak (RedHat, Fedora, GNOME) dhe Snappy (Canonical, Ubuntu). Arrin në qesharake.

Si funksionon gjithçka

Çdo AppImage përmban dy pjesë: një ekzekutues të vogël me dy klikime ELF (në mënyrë të njohur si runtime.c), me pas përmbajtjen e sistemit të skedarëve SquashFS.

Sistemi i skedarëve SquashFS përmban ngarkesën e nevojshme për aplikacionin dhe gjithçka tjetër që është e nevojshme për ta bërë atë të funksionojë, e cila në mendje të shëndoshë nuk mund të konsiderohet si pjesë e instalimit të parazgjedhur për çdo sistem të ri të mjaftueshëm (distribuimi Linux). Ajo gjithashtu përmban të dhëna mbi metadat, si emri i aplikacionit, ikonat, llojet MIME, etj.

Kur përdoruesi e nis, runtime përdor FUSE dhe squashfuse për të montuar sistemin e skedarëve, dhe më pas trajton fillimin e një pike hyrjeje (të ashtuquajturën AppRun) brenda AppImage të montuar.
Sistemi i skedarëve shkëputet pasi të përfundojë procesi.

Duket si e thjeshtë.

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

me një përzierje kaq të madhe të distribucioneve Linux, asgjë nuk mund të quhet "në mendje të shëndoshë" si "pjesë e instalimit të parazgjedhur për çdo sistem të ri". Ne e zgjidhim këtë problem duke mbledhur excludelist, që lejon të përcaktojmë se çfarë do të paketojmë në AppImage dhe çfarë do të duhet të merret diku tjetër. Megjithatë, ndonjëherë gabojmë, megjithëse në përgjithësi gjithçka funksionon për bukuri. Për këtë arsye, ne rekomandojmë krijuesve të paketave që të verifikojnë AppImages në të gjitha sistemet e synuara (distribuimet).
Aplikacionet si ngarkesa duhet të jenë të lëvizshme në sistemin e skedarëve. Fatkeqësisht, shumë aplikacione kanë rrugë absolute të përcaktuara fort, për shembull, për burimet në /usr/share. Kjo duhet ndrequr në një farë mënyre. 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. Mënyra e parë ka disavantazhe të veta (të cilat merren me metoda komplekse), ndërsa e dyta është thjesht e bezdisshme.
Tragjedia më e madhe e UX për përdoruesit është se duhet të vendosni bitin zhvillues në skedarin AppImage pas shkarkimit. Besoni ose jo, por për disa është një pengesë e vërtetë. Kërkesa për vendosjen e bitit të ekzekutimit është e bezdisshme edhe për përdoruesit e përvojshëm. Si një zgjidhje alternative, ne propozuam instalimin e një shërbimi të vogël që monitoron skedarët AppImage dhe vendos bitin e ekzekutimit për ta. Në formën e pastër, nuk është zgjidhja më e mirë, pasi nuk do të funksionojë "nga kutia". Distribucioni Linux nuk ofron këtë shërbim, prandaj përdoruesit "nga kutia" kanë probleme.
Përdoruesit e Linux presin që aplikacioni i ri të ketë një ikonë në menunë e fillimit. Sistemi nuk mund t’i thuash: «Shiko, ka një aplikacion të ri, le të punojë». Në vend të kësaj, sipas specifikimeve XDG, duhet të kopjosh skedarin .desktop në vendin e duhur në /usr për instalim sistemik të përgjithshëm, ose në $HOME për individë. Ikonat e disa madhësive, sipas specifikimeve XDG, duhet të vendosen në vende të caktuara në usr ose $HOME, pas së cilës duhet të ekzekutosh komandat në mjedisin e punës për të përditësuar në cache ikonat, ose të shpresosh që menaxheri i mjedisit të punës do të kuptojë dhe do t’i zbulojë automatikisht të gjitha. Po ashtu me llojet MIME. Si një anashkalim, propozohet përdorimi i të njëjtit shërbim që, përveç që vendos shenjën e ekzekutueshmërisë, nëse ka ikona e tjera në AppImage, do t’i kopjojë ato nga AppImage në vendet e duhura sipas XDG. Kur fshihet ose zhvendoset, shërbimi supozohet se do të pastronte gjithçka. Sigurisht, ka dallime në sjelljen e çdo mjedisi pune, në formatet e skedarëve grafikë, madhësitë e tyre, vendet e ruajtjes dhe metodat e përditësimit të caches, gjë që krijon problemin. Në përmbledhje, ky është një zgjidhje e përkohshme.
Nëse e gjithë kjo nuk është e mjaftueshme, në menaxherin e skedarëve nuk ka asnjë ikonë AppImage. Në botën e Linux-it, ende nuk është marrë një vendim për implementimin e elficon (pavarësisht nga diskutimi dhe realizimit), kështu që nuk është e mundur të integrohet një ikonë direkt në aplikacion. Kështu që ndodh që aplikacionet në menaxherin e skedarëve nuk kanë ikona të tyre (nuk ka rëndësi, AppImage apo diçka tjetër), ato janë vetëm në menunë e nisjes. Si një zgjidhje alternative, 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 të parashikuar skedarët grafikë si ikona të tyre. Prandaj, shërbimi për vendosjen e bitit të ekzekutueshmërisë gjithashtu funksionon si "miniaturizues", duke krijuar dhe regjistruar miniaturat e ikonave në vendet përkatëse /usr dhe $HOME. Gjithashtu, ky shërbim kryen një pastrim nëse AppImage fshihet ose tërhiqet. Për shkak se çdo menaxher desktopi sillet pak ndryshe, për shembull, në formatet që pranon ikonat, në dimensionet ose vendet e tyre, të gjitha këto janë vërtet të dhimbshme.
Aplikacioni thjesht shembet gjatë ekzekutimit nëse ka gabime (për shembull, nëse ekziston një bibliotekë që nuk është pjesë e sistemit bazë dhe nuk ofrohet në AppImage), dhe askush nuk i thotë përdoruesit në GUI se çfarë ndodh konkretisht. Ne filluam ta kapërcejmë këtë duke përdorur njoftime në desktop, çka do të thotë se duhet të kapi gabimet nga linja e komandës, t'i kthejë ato në mesazhe të kuptueshme për përdoruesin, të cilat duhet gjithashtu të shfaqen në desktop. Dhe sigurisht, çdo mjedis punimi i trajton ato paksa ndryshe.
Në këtë moment (shtator 2019, — shënimi i përkthyesit) nuk kam gjetur një mënyrë të thjeshtë për t'i thënë sistemit që skedari 1.png duhet të hapet me Krita, ndërsa 2.png — me GIMP.

Vendi i ruajtjes së specifikimeve cross-desktop, të përdorura në GNOME, KDE dhe Xfce është freedesktop.org

Arritja e një niveli sofistikimi, thellësisht e përfshirë në mjedisin e punës Haiku, është e vështirësuar, nëse jo "e pamundur", për shkak të specifikimeve XDG nga freedesktop.org për cross-desktop, si dhe realizimeve të menaxherëve të desktopit bazuar në këto specifikime. Një shembull mund të jetë një ikonë e përgjithshme e sistemit Firefox: duket se autorët e XDG nuk e kanë menduar që një përdorues mund të ketë instaluar disa versionet e njëjtë të aplikacionit.

Ikonat e versioneve të ndryshme të Firefox

Më interesonte se çfarë mund të mësonte bota e Linux nga Mac OS X, për të mos dështuar në integrimin e sistemit. Nëse keni kohë dhe jeni të angazhuar në këtë, sigurisht që duhet të lexoni se çfarë tha Arno Gourdol, një nga inxhinierët e parë të Mac OS X:

Ne do ta dojmë që instalimi i një aplikacioni është po aq i thjeshtë sa të shdragosh ikonën e tij nga ndonjë vend (server, disk i jashtëm) në diskun e kompjuterit tënd. Për këtë qëllim, paketa e aplikacionit përmban të gjitha informacionet, përfshirë ikonat, versionin, llojin e skedarëve që përpunohen, dhe llojin e skemës së URL-së që sistemi duhet ta dijë për të menaxhuar aplikacionin. Këtu përfshihet gjithashtu 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 ‘shkelen’ në disa vende ‘të njohura mirë’: në katalogun sistematik dhe atë personal të Aplikacioneve, si dhe në disa vende 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 sesi 144 — Mac OS X: paketimi i aplikacioneve dhe printimi i dokumenteve.

Nuk ka asnjë gjë të ngjashme nga kjo infrastrukturë në ambientet e punës Linux, prandaj po kërkojmë anë rreth kufizimeve strukturore në projektin AppImage.

A është Haiku në ngutje për të ndihmuar?

Dhe gjithashtu: platformat Linux si bazë për mjediset e punës janë zakonisht aq të keqpecaktuara, saqë shumë gjëra që janë mjaft të thjeshta në një sistem të koherencës me një grumbull të plotë, zhgënjejnë me fragmetimin dhe kompleksitetin në Linux. Kam dedikuar një tërë referat për çështjet e platformës Linux për mjediset e punës (të njohurit e zhvilluesve konfirmuan: kjo do të vazhdojë të mbetet për një kohë të gjatë).

Referati im mbi problemet e mjediseve të punës Linux në 2018

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

E këndshme të shoh Haiku!

Me Haiku gjithçka bëhet jashtëzakonisht e thjeshtë

Megjithëse qasja naive për "transferren" AppImage në Haiku konsiston në një përpjekje të thjeshtë për të ndërtuar (në thelb runtime.c dhe shërbimin) komponentët e tij (çka mund të jetë edhe e mundur!), ajo nuk do të sjellë dobi të veçantë 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 ndihmës për infrastrukturën sistemore që kam kërkuar kaq gjatë në mjediset e punës në Linux dhe nuk mund të besoja që ato nuk ishin atje. E ata janë:

Besoni ose jo, por shumë përdorues të Linux-it nuk mund ta përballojnë këtë. Në Haiku, gjithçka bëhet automatikisht!

Skedarët ELF që nuk kanë bitin e ekzekutueshëm e fitojnë atë automatikisht kur dyfishtë klikoni në menaxherin e skedareve.
Aplikacionet mund të kenë burime të ndërtuara brenda, për shembull ikona, të cilat shfaqen në menaxherin e skedareve. Nuk është e nevojshme të kopjoni një grumbull imazhesh në katalogë të veçantë për ikona, prandaj nuk është e nevojshme t'i pastroni ato pas fshirjes ose zhvendosjes së aplikacionit.
Ekziston një bazë të dhënash për lidhjen e aplikacioneve me dokumentet, nuk ka nevojë të kopjoni ndonjë skedar për këtë.
Në katalogun lib/ pranë skedarit ekzekutues, kërkohen si standard.
Nuk ka shumë distribucione dhe mjedise desktopi, çdo gjë që funksionon - funksionon kudo.
Nuk ekziston një moduli i veçantë për nisje që të ndryshojë nga katalogu i Aplikacioneve.
Në aplikacione, nuk ka rrugë absolute të ndërtuara brenda për burimet e tyre, ka funksione speciale për të përcaktuar vendndodhjen gjatë ekzekutimit.
Ideja e imazheve të kompresuara të sistemeve të skedarëve është e integruar: çdo paketë hpkg është një e tillë. Të gjitha ato montohen nga bërthama.
Çdo skedë hapet me aplikacionin që e ka krijuar, nëse nuk tregohet ndryshe. Sa e bukur është kjo!

Dy skedarë png. Vëreni ikonat e ndryshme që tregojnë se ato do të hapen me aplikacione të ndryshme kur iu bëhet dyfish klik. Gjithashtu, vini re menu nga zbarkimi "Hap me:" ku përdoruesi mund të zgjedhë një aplikacion të veçantë. Sa e lehtë!

Duket se shumë nga ndihmat dhe anashkalimet që janë të nevojshme për AppImage në Linux, bëhen të panevojshme në Haiku, e cila ka si bazë thjeshtësinë dhe rafinimin, që e ndihmojnë atë të përballojë shumicën e nevojave tona.

A kërkohen paketa aplikacionesh në Haiku, përfundimisht?

Kjo e çon në një pyetje të madhe. Nëse do të ishte shumë më e lehtë të krijohej një sistem si AppImage në Haiku sesa në Linux, a do të kishte vlerë kjo të merret parasysh? Apo, a e ka eliminuar sistemi i paketave hpkg i Haiku nevojën për zhvillimin e një ideje të tillë? Tani, për të përgjigjur, duhet të shohim motivimin e ekzistencës së AppImages.

Një këndvështrim nga përdoruesi

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

Dua të instaloj një aplikacion pa kërkuar fjalëkalimin e administratorit (root). Në Haiku nuk ka konceptin e administratorit, përdoruesi ka kontroll të plotë, pasi kjo është një sistem personal! (Në parim, mund ta imagjinoni edhe në modin shumëpërdorues, shpresoj që zhvilluesit të ruajnë thjeshtësinë)
Dua të marr versionet më të fundit dhe më të mira të aplikacioneve, pa pritur që ato të shfaqen në distribucionin tim (më së shpeshti kjo do të thotë 'kurrë', së paku, nëse nuk përditësoj gjithashtu sistemin operativ). Në Haiku kjo është "zgjidhur" përmes lëshimeve të kaluara. 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ësohen vazhdimisht edhe pjesët e tjera të sistemit, duke e kthyer atë në një "objekt në lëvizje"..
Më pëlqen të kem disa versione të të njëjtit aplikacion këtu pranë, pasi nuk mund të di se çfarë është prishur në versionin më të fundit, ose, themi, si zhvillues web-i, duhet të verifikoj punën time nën versione të ndryshme të naviguesve. Në Haiku është zgjidhur problemi i parë, por jo problemi i dytë. Përditësimet rrotullohen prapa, por vetëm për sistemin e tërë, ndonëse (sa di unë) nuk është e mundur të ekzekutoni, për shembull, disa versione të WebPositive ose LibreOffice njëkohësisht.

Një nga zhvilluesit shkruan:

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

Unë kam nevojë të ruaj aplikacionet aty ku më pëlqen, dhe jo në disqin e ngarkesës. Në disqe shpesh më përfundon hapësira, kështu që duhet të lidhem me një disk të jashtëm ose një katalog në rrjet për të ruajtur aplikacione (të gjitha versionet që kam shkarkuar). Nëse lidhem me një disk të tillë — aplikacionet duhet të nisin me një klikim të dyfishtë. Haiku ruan versionet e vjetra të paketave, por nuk e di si t'i çoj ato në diskun e jashtëm, as si të filloj aplikacionet nga aty.

Koment i zhvilluesit:

Në mënyrë teknike, kjo tashmë është e mundur me komandën mount. Sigurisht, ne do të bëjmë një GUI për këtë, sapo të ketë mjaft përdorues të interesuar.

Nuk kam nevojë për miliona skedarë të shpërndarë në sistemin e skedarëve, të cilët nuk mund t'i menaxhoj vetë manualisht. Dua një skedar për aplikacion, të cilin mund ta shkarkoj, ta transferoj, ta fshij lehtësisht. Në Haiku ky problem zgjidhet përmes paketave .hpkg, të cilat transferojnë, për shembull python, nga mijëra skedare në një. Por nëse ka, për shembull, Scribus që përdor python, atëherë më duhet të merrem të paktën me dy skedare. Dhe unë duhet të kujdesem për të ruajtur versionet e tyre që punojnë së bashku.

Versione të shumta të AppImages, që ekzekutohen afër njëra-tjetrës në një Linux.

Një këndvështrim nga perspektiva e zhvilluesit të aplikacioneve.

Le të shohim nga këndvështrimi i zhvilluesit të aplikacioneve:

Unë dua të menaxhoj përvojën e përdoruesit në tërësi. Nuk dua të varet nga sistemi operativ, i cili do të më tregojë kur dhe si duhet të lëshoj aplikacionet. Në Haiku, zhvilluesit mund të punojnë me repozitorët e tyre hpkg, por kjo do të thotë që 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ë webin tim, ku shpërndaj .exe për Windows, .dmg për Mac dhe .AppImage për Linux. Dhe ndoshta, dua të monetizoj qasjen në këtë faqe, gjithçka është e mundur? Çfarë duhet të vendos atje për Haiku? Mjafton një skedar .hpkg me varësi vetëm nga HaikuPorts.
Programi im kërkon versione të caktuar të softuerëve të tjerë. Për shembull, dihet se për Krita nevojitet një version i rregulluar i Qt, ose Qt që është saktësisht e konfiguruar për një version të veçantë të Krita, të paktën deri sa riparimet të kthehen në Qt. Mund të paketoni Qt të vetin për aplikacione brenda paketës. .hpkg, por shumë gjasa, kjo nuk është mirëpritur.

Një faqe e zakonshme e shkarkimit për aplikacione. Çfarë duhet të vendosim këtu për Haiku?

A do të jenë paketat (të pranishme si katalogë aplikacionesh, si AppDir ose .app në stilin Apple) dhe/ose imazhet (në formën e AppImages të modifikuara shumë ose .dmg nga Apple) të aplikacioneve një shtesë e dobishme për ambientin e punës Haiku? Apo do ta shqetësojnë pamjen e përgjithshme dhe do të shkaktojnë fraktim, duke e bërë kështu më të komplikuar? Unë jam i ngarkuar: nga njëra anë, bukuria dhe delikatesa e Haiku janë të bazuara në atë që zakonisht ka një mënyrë për të bërë diçka, e jo shumë. Nga ana tjetër, një pjesë e madhe e infrastrukturës për katalogët dhe/ose paketat aplikacionesh është tashmë në vend, kështu që sistemi kërkon që të rregullohen dhe disa përqindje e mbetur.

Sipas zhvilluesit mr. waddlesplash

Në Linux ato (kataloge dhe grupe aplikacionesh, — shënim i përkthyesit) ndoshta janë një zgjidhje teknike për problemet sistemike. Në Haiku ne preferojmë thjesht të zgjidhim problemet sistemike.

Po, çfarë mendoni ju?

Para se të përgjigjeni…

Pritni, le të bëjmë një kontroll të shpejtë të realitetit: në fakt kataloge aplikacionesh — janë tashmë pjesë e Haiku:

Kataloget e aplikacioneve ekzistojnë tashmë në Haiku, por për momentin nuk mbështeten në menaxherin e skedarëve

Ato thjesht nuk mbështeten aq mirë sa, për shembull, në Finder të Macintosh. Çfarë do të ishte e bukur nëse katalogu QtCreator do të kishte emrin dhe ikonën «QtCreator» në këndin e sipërm të majtë që do të nisnin aplikacionin me dy klikime?

Pak më parë unë tashmë pyeta:

A jeni të sigurt se do të nisni aplikacionet tuaja të dekadës së kaluar sot, kur të gjitha dyqanet e aplikacioneve dhe repository-t e distribucioneve do të harrojnë për to dhe varësitë e tyre? A jeni të sigurt se do të mund të aksesoni punën tuaj aktuale në të ardhmen?

A ka ndonjë përgjigje nga Haiku, apo kataloget dhe grupet e aplikacioneve mund të ndihmojnë këtu? Mendoj se mund të ndihmojnë.

Sipas zotit waddlesplash:

Po, ne kemi një përgjigje për pyetjen: ne thjesht do të mbajmë këto aplikacione sa herë që është e nevojshme, derisa dikush të mund t'i lexojë formatet e tyre të skedarëve siç duhet ose të ofrojë funksionalitet një për një. Përkushtimi ynë për të mbajtur aplikacionet BeOS R5 të funksionojnë në Haiku është një dëshmi e drejtpërdrejtë për këtë…

Është e vërtetë!

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

Unë mund të imagjinoj një bashkëjetesë paqësore mes hpkg, katalogëve dhe imazheve të aplikacioneve:

Programi i sistemit përdor .hpkg
Për softuerin më të përdorur (veçanërisht për atë që kërkon të planifikojë lëshime të paqëndrueshme) përdoret .hpkg (afërsisht 80% e rasteve të gjitha)
Disa, të instaluara përmes .hpkg, aplikacioneve do të përfitojnë nga kalimi në një infrastrukturë 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ë është e nevojshme, është të shihen aplikacionet në /system/apps, në vend të kësaj duhet të bëhen katalogët në Deskbar më të menaxhueshëm për përdoruesit, pasi /system/apps nuk është e destinuar që përdoruesit ta hapin dhe ta shohin atë rregullisht (ndryshe nga MacOS). Për situata të tilla, Haiku ka një paradigmë tjetër, por kjo mundësi, në teori, është e pranuar.

Haiku merr infrastrukturën për të funksionuar imazhe aplikacionesh, ndërtime të natës, ndërtime të vazhdueshme dhe testuese të softuerit, si dhe për rastet kur përdoruesi dëshiron ta "përzgjedhë atë në kohë", përsoftuer të privatë dhe të brendshëm, dhe raste të tjera të veçanta përdorimi (rreth 20% të të gjitha). Këto imazhe përmbajnë skedarët e nevojshëm për të hapur aplikacionin .hpkg, të montuara nga sistemi, dhe pas përfundimit të aplikacionit – të paketuara. (Ndoshta menaxheri i skedarëve mund të vendosë skedarët .hpkg në imazhet e aplikacionit, automatikisht ose me kërkesë të përdoruesit – ashtu siç ndodh kur tërheq një aplikacion në një katalog rrjeti ose një disk të jashtëm. Kjo është thjesht një këngë! Apo më saktë 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 do të përditësohen dhe do të përpunohen pikërisht siç do ishin instaluar përmes HaikuDepot… Duhet të bëjmë një brainstorming).

Cita nga z. waddlesplash:

Ekzekutimi i aplikacioneve nga disqe të jashtme ose katalogë rrjeti mund të jetë shumë i dobishëm. Shtimi i mundësisë për të konfigurimi të më shumë "zona" për pkgman do të ishte një veçori e madhe.

Një sistem i tillë do të shfrytëzojë përparësitë e hpkg, katalogëve dhe imazheve të aplikacioneve. Ata janë të shkëlqyer edhe veç e veç, por së bashku do të bëhen të papërmbajtshëm.

Përfundimi

Për Haiku ekziston një infrastrukturë që ofron një ndërfaqe të thjeshtë dhe të sofistikuar për PC-të, duke dalë shumë përtej asaj që zakonisht ofrohet për PC-të në Linux. Sistemi i paketave .hpkg — një nga ato shembuj, por pjesët e tjera të sistemit janë gjithashtu të mbushura me përparësi. Megjithatë, mbështetje e duhur për katalogët dhe imazhet e aplikacioneve do të ishin përfitues për Haiku. Si është më mirë ta realizojmë këtë, duhet ta diskutojmë me njerëz që e njohin Haiku, filozofinë dhe arkitekturën e saj shumë më mirë se unë. Në fund të fundit, po e përdor Haiku për pak më shumë se një javë. Megjithatë, unë mendoj se ky këndvështrim i ri do të jetë i dobishëm për dizajnerët, zhvilluesit dhe arkitektët e Haiku. Të paktën, unë do të jem i lumtur të jem një "partner sparr" për ta. Kam më shumë se 10 vjet përvojë praktike me katalogët dhe grumbujt e aplikacioneve për Linux, dhe do të doja t'i gjej një përdorim për Haiku, për konceptin e të cilit, sipas mendimit tim, ata përshtaten perfekt. Zgjidhjet e propozuara nga unë nuk janë të vetmet të sakta për problemet që përshkrova, dhe nëse ekipi i Haiku vendos të gjejë të tjera, më elegante — unë nuk kam asnjë problem me këtë. Në parim, unë tashmë po mendoj për idenë se si ta bëj sistemin hpkg edhe më të mahnitshme, pa ndryshuar mënyrën se si funksionon. Duket se ekipi i Haiku ka menduar prej kohësh për paketat e aplikacioneve gjatë implementimit të sistemit të menaxhimit të paketave, por fatkeqësisht, (më duket) ideja ka shkuar në " të vjetra". Ndoshta ka ardhur koha ta ringjallim atë?

Provo vetë! Projektin Haiku ofron imazhe për ngarkim me DVD ose USB, të krijuara çdo ditë.
Keni pyetje? Ju ftojmë në kanalin rusishtfolës të telegramit.

Pasqyrë e gabimeve: Si të të godasësh në këmbë me C dhe C++. Katalogu i recetave Haiku OS

Nga autori përkthimit: kjo është artikulli i tetë dhe përfundimtar i ciklit mbi Haiku.

Lista e artikujve: E para E dyta E treta E katërta E pesta E gjashta E shtata

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