Io alia: hajko-aplikaĵoj?

TL; DR: Ĉu Hajko povas ricevi taŭgan subtenon por aplikaĵpakaĵoj, kiel aplikaĵaj dosierujoj (kiel .app en Mac) kaj/aŭ aplikaĵbildoj (Linukso AppImage)? Mi pensas, ke ĉi tio estus inda aldono, kiu estas pli facile efektivigi ĝuste ol aliaj sistemoj, ĉar la plej granda parto de la infrastrukturo jam estas en loko.

Antaŭ unu semajno Mi malkovris Hajkon, neatendite bonan sistemon. Nu, ĉar delonge mi interesiĝas pri dosierujoj kaj aplikaĵbildoj (inspiritaj de la simpleco de la Makintoŝo), ne estas mirinde, ke ideo venis al mi en la kapon...

Por plena kompreno, mi estas la kreinto kaj aŭtoro de AppImage, Linukso-aplika distribua formato kiu celas Mac-simplecon kaj donas plenan kontrolon al aplikaĵaŭtoroj kaj finaj uzantoj (se vi volas scii pli, vidu vikio и dokumentado).

Kio se ni faras AppImage por Hajko?

Ni pripensu iomete, pure teorie: kion oni devas fari por atingi AppImage, aŭ io simila, pri Hajko? Ne necesas krei ion nun, ĉar la sistemo, kiu jam ekzistas en Hajko, funkcias mirinde, sed imaga eksperimento estus bone. Ĝi ankaŭ montras la sofistikecon de Hajko, kompare kun Linuksaj labortablaj medioj, kie tiaj aferoj estas terure malfacilaj (mi rajtas diri tion: mi luktas kun senararigado dum 10 jaroj).

Sur la Makintoŝo-Sistemo 1, ĉiu aplikiĝo estis aparta dosiero "administrita" en la Finder. Uzante AppImage mi provas rekrei la saman sperton de uzanto en Linukso.

Unue, kio estas AppImage? Ĉi tio estas sistemo por eldonado de triapartaj aplikoj (ekzemple, Ultimaker Kuraco), permesante al aplikoj esti liberigitaj kiam kaj kiel ili volas: ne necesas scii la specifaĵojn de diversaj distribuoj, konstrui politikojn aŭ konstrui infrastrukturon, neniu prizorganto-subteno estas necesa, kaj ili ne diras al uzantoj kion (ne) ili povas instali. sur siaj komputiloj. AppImage devus esti komprenata kiel io simila al Mac-pakaĵo en la formato .app ene de la disko bildo .dmg. La ĉefa diferenco estas, ke aplikaĵoj ne estas kopiitaj, sed restas ene de la AppImage por ĉiam, same kiel Haiku-pakaĵoj. .hpkg muntita, kaj neniam instalita en la kutima signifo.

Dum pli ol 10 jaroj da ekzisto, AppImage akiris iom da allogo kaj populareco: Linus Torvalds mem publike aprobis ĝin, kaj komunaj projektoj (ekzemple, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) adoptis ĝin kiel la ĉefan manieron. distribui daŭrajn aŭ noktajn konstruaĵojn, ne malhelpante instalitajn aŭ malinstalitajn uzantaplikaĵojn. Tamen, Linuksaj labortablaj medioj kaj distribuoj plej ofte ankoraŭ alkroĉiĝas al la tradicia, centralizita prizorganto-bazita distribua modelo kaj/aŭ antaŭenigas siajn proprajn entreprenajn komercajn kaj/aŭ inĝenierajn programojn bazitajn sur Flatpak (RedHat, Fedora, GNOME) kaj Rapida (Kanonika, Ubuntu). Ĝi venas ridinde.

Kiel ĉio funkcias

• Ĉiu AppImage enhavas 2 partojn: malgranda duobla klako ELF (t.n. runtime.c), sekvita de dosiersistembildo SquashFS.

• La dosiersistemo SquashFS enhavas la utilan ŝarĝon de la aplikaĵo kaj ĉion necesan por ruli ĝin, kio en ĝusta menso ne povas esti konsiderata parto de la defaŭlta instalo por ĉiu sufiĉe lastatempa celsistemo (Linuksa distribuo). Ĝi ankaŭ enhavas metadatenojn, kiel ekzemple la aplikaĵnomo, ikonojn, MIME-tipojn, ktp., ktp.

• Kiam ĝi estas prizorgita de la uzanto, rultempo uzas FUSE kaj squashfuse por munti la dosiersistemon, kaj tiam pritraktas prizorgi iun enirpunkton (alinome AppRun) ene de la muntita AppImage.
  La dosiersistemo estas malmuntita post kiam la procezo finiĝas.

Ĉio ŝajnas simpla.

Kaj ĉi tiuj aferoj komplikas ĉion:

• Kun tia gamo da Linukso-distribuoj, nenio "en la ĝusta menso" povas esti nomata "parto de la defaŭlta instalo por ĉiu nova celsistemo." Ni traktas ĉi tiun aferon per konstruado ekskludisto, permesante al vi determini kio estos pakita en la AppImage kaj kio devos esti prenita aliloken. Samtempe, ni foje mankas, malgraŭ ke, ĝenerale, ĉio funkcias bonege. Tial ni rekomendas, ke pakaĵkreantoj provu AppImages sur ĉiuj celsistemoj (distribuoj).
• Aplikaj utilaj ŝarĝoj devas esti translokeblaj tra la dosiersistemo. Bedaŭrinde, multaj aplikoj havas malmolajn absolutajn vojojn al, ekzemple, rimedoj en /usr/share. Ĉi tio devas esti riparita iel. Krome, vi devas aŭ eksporti LD_LIBRARY_PATH, aŭ ripari rpath tiel ke la ŝargilo povas trovi rilatajn bibliotekojn. La unua metodo havas siajn malavantaĝojn (kiuj estas venkitaj en kompleksaj manieroj), kaj la dua estas simple maloportuna.
• La plej granda UX-falo por uzantoj estas tio agordi ruleblan biton AppImage dosiero post elŝuto. Kredu ĝin aŭ ne, ĉi tio estas vera baro por iuj. La bezono agordi la ekzekuteblecon estas maloportuna eĉ por spertaj uzantoj. Kiel solvo, ni sugestis instali malgrandan servon, kiu monitoras AppImage-dosierojn kaj agordas ilian ekzekuteblecon. En ĝia pura formo, ĝi ne estas la plej bona solvo, ĉar ĝi ne funkcios el la skatolo. Linukso-distribuoj ne provizas ĉi tiun servon, tial uzantoj havas malbonan sperton el la skatolo.
• Linukso-uzantoj atendas ke nova aplikaĵo havu ikonon en la startmenuo. Vi ne povas diri al la sistemo: "Rigardu, estas nova aplikaĵo, ni laboru." Anstataŭe, laŭ la XDG-specifo, vi devas kopii la dosieron .desktop al la ĝusta loko en /usr por tutsistema instalado, aŭ en $HOME por individuo. Ikonoj de certaj grandecoj, laŭ la XDG-specifo, devas esti metitaj en certajn lokojn usr aŭ $HOME, kaj poste rulu komandojn en la labormedio por ĝisdatigi la ikonan kaŝmemoron, aŭ esperu, ke la labormedio-administranto eltrovos ĝin kaj aŭtomate detektos ĉion. Same kun MIME-tipoj. Kiel solvo, estas proponite uzi la saman servon, kiu, krom agordi la ekzekutebla flago, faros, se estas ikonoj, ktp. en AppImage, kopiu ilin de AppImage al la ĝustaj lokoj laŭ XDG. Kiam forigita aŭ movita, la servo estas atendita purigi ĉion. Kompreneble, estas diferencoj en la konduto de ĉiu labormedio, en grafikaj dosierformatoj, iliaj grandecoj, stokaj lokoj kaj metodoj por ĝisdatigi kaŝmemorojn, kio kreas problemon. Resume, ĉi tiu metodo estas lambastono.
• Se ĉi-supra ne sufiĉas, ankoraŭ ne ekzistas AppImage-ikono en la dosieradministranto. La Linukso-mondo ankoraŭ ne decidis efektivigi elficon (malgraŭ diskuto и efektivigo), do estas neeble enigi la ikonon rekte en la aplikaĵon. Do rezultas, ke aplikaĵoj en la dosieradministranto ne havas siajn proprajn ikonojn (neniu diferenco, AppImage aŭ io alia), ili estas nur en la komenca menuo. Kiel solvo, ni uzas bildetojn, mekanismon kiu estis origine desegnita por permesi labortablaj administrantoj montri bildetojn antaŭprezentajn bildojn de grafikaj dosieroj kiel iliaj ikonoj. Sekve, la servo por agordi la ekzekutebla bito ankaŭ funkcias kiel "miniaturigilo", kreante kaj skribante ikonajn bildetojn al la taŭgaj lokoj. /usr и $HOME. Ĉi tiu servo ankaŭ faras purigadon se la AppImage estas forigita aŭ movita. Pro la fakto, ke ĉiu labortabla administranto kondutas iomete malsame, ekzemple, en kiaj formatoj ĝi akceptas ikonojn, en kiaj grandecoj aŭ lokoj, ĉi tio estas vere dolora.
• La aplikaĵo simple kraŝas dum ekzekuto se okazas eraroj (ekzemple, ekzistas biblioteko kiu ne estas parto de la baza sistemo kaj ne estas provizita en AppImage), kaj neniu diras al la uzanto en la GUI kio ĝuste okazas. Ni komencis ĉirkaŭiri ĉi tion uzante sciigoj sur la labortablo, kio signifas, ke ni devas kapti erarojn de la komandlinio, konverti ilin en uzant-komprenitajn mesaĝojn, kiuj tiam devas esti montrataj sur la labortablo. Kaj kompreneble ĉiu labortabla medio pritraktas ilin iomete malsame.
• Nuntempe (septembro 2019 - noto de la tradukinto) mi ne trovis simplan manieron diri al la sistemo, ke la dosiero 1.png devas esti malfermita uzante Krita, kaj 2.png - uzante GIMP.

Stokloko por trans-tablaj specifoj uzataj en GNOME, KDE и Xfce estas freedesktop.org

Atingi la nivelon de sofistikeco profunde teksita en la hajkuan labormedion estas malfacila, se ne malebla, pro la specifoj. XDG de freedesktop.org por transskribotablo, same kiel efektivigoj de labortablaj administrantoj bazitaj sur ĉi tiuj specifoj. Kiel ekzemplo, ni povas citi unu sistem-kovrantan Firefox-ikonon: ŝajne, la aŭtoroj de XDG eĉ ne pensis, ke uzanto povus havi plurajn versiojn de la sama aplikaĵo instalitaj.

Ikonoj por malsamaj versioj de Firefox

Mi scivolis, kion la Linukso-mondo povus lerni de Mac OS X por eviti fuŝi sisteman integriĝon. Se vi havas tempon kaj ŝatas ĉi tion, nepre legu tion, kion diris Arnaud Gurdol, unu el la unuaj inĝenieroj de Mac OS X:

Ni volis fari instali la aplikaĵon tiel facila kiel treni la aplikaĵan ikonon de ie (servilo, ekstera disko) al via komputila stirado. Por fari tion, la aplikaĵa pakaĵo konservas ĉiujn informojn, inkluzive de ikonoj, versio, dosiero-tipo prilaborata, specoj de URL-skemoj, kiujn la sistemo bezonas scii por prilabori la aplikaĵon. Ĉi tio ankaŭ inkluzivas informojn pri "centra stokado" en la datumbazo de Ikonaj Servoj kaj Lanĉaj Servoj. Por subteni agadon, aplikaĵoj estas "malkovritaj" en pluraj "konataj" lokoj: la dosierujoj de sistemo kaj uzantAplikoj, kaj iuj aliaj aŭtomate se la uzanto navigas al la Trovilo en la dosierujo enhavanta la aplikaĵon. En praktiko tio funkciis tre bone.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000-sesio 144 - Mac OS X: pakaj aplikaĵoj kaj presaj dokumentoj.

Estas nenio kiel ĉi tiu infrastrukturo sur Linuksaj labortabloj, do ni serĉas solvojn ĉirkaŭ la strukturaj limigoj en la projekto AppImage.

Ĉu Hajko venas al la savo?

Kaj ankoraŭ unu afero: Linuksaj platformoj kiel bazo de labortablaj medioj tendencas esti tiom subspecifitaj, ke multaj aferoj, kiuj estas sufiĉe simplaj en konsekvenca plenstaka sistemo, estas frustre fragmentaj kaj kompleksaj en Linukso. Mi dediĉis tutan raporton al aferoj rilataj al la Linukso-platformo por labortablaj medioj (konitaj programistoj konfirmis, ke ĉio restos tiel dum tre longa tempo).

Mia raporto pri la problemoj de Linuksaj labortablaj medioj en 2018

Eĉ Linus Torvalds konfesis, ke fragmentiĝo estis kial la laborspaca ideo malsukcesis.

Agrable vidi Hajkon!

Hajko faras ĉion mirinde simpla

Dum la naiva aliro al "portado" de AppImage al Hajko estas simple provi konstrui (ĉefe runtime.c kaj servo) ĝiajn komponantojn (kiuj eĉ povas esti eblaj!), ĉi tio ne multe profitos al Hajko. Ĉar fakte, la plej multaj el tiuj problemoj estas solvitaj en Hajko kaj estas koncipe solidaj. Hajko provizas ĝuste la sistemajn infrastrukturajn konstrubriketojn, kiujn mi serĉis en Linuksaj labortablaj medioj dum tiom da tempo kaj mi ne povis kredi ke ili ne estas tie. Nome:

Kredu aŭ ne, ĉi tio estas io, kion multaj Linukso-uzantoj ne povas venki. Ĉe Hajko ĉio fariĝas aŭtomate!

• ELF-dosieroj, kiuj ne havas efektivigeblan biton, ricevas unu aŭtomate kiam duoble alklakitaj en la dosieradministranto.
• Aplikoj povas havi enkonstruitajn rimedojn, kiel ikonojn, kiuj estas montrataj en la dosieradministranto. Ne necesas kopii amason da bildoj en specialajn dosierujojn kun ikonoj, kaj tial ne necesas purigi ilin post forigo aŭ movi la aplikaĵon.
• Estas datumbazo por ligi aplikojn kun dokumentoj, por tio ne necesas kopii ajnajn dosierojn.
• En la dosierujo lib/ apud la plenumebla dosiero, bibliotekoj estas serĉataj defaŭlte.
• Ne ekzistas multaj distribuoj kaj labortablaj medioj; kio ajn funkcias, funkcias ĉie.
• Ne ekzistas aparta modulo por ruli, kiu diferencas de la dosierujo Aplikoj.
• Aplikoj ne havas enkonstruitajn absolutajn vojojn al siaj resursoj; ili havas specialajn funkciojn por determini la lokon ĉe rultempo.
• La ideo de kunpremitaj dosiersistemaj bildoj estis enkondukita: ĉi tiu estas ajna hpkg-pakaĵo. Ĉiuj ili estas muntitaj de la kerno.
• Ĉiu dosiero estas malfermita de la aplikaĵo kiu kreis ĝin, krom se vi eksplicite specifas alie. Kiel mojosa estas ĉi tio!

Du png dosieroj. Notu la malsamajn ikonojn indikante, ke ili estos malfermitaj de malsamaj aplikaĵoj kiam duoble alklakos. Notu ankaŭ la falmenuon "Malfermu per:", kie la uzanto povas elekti individuan aplikaĵon. Kiel simple!

Ŝajnas, ke multaj el la lambastonoj kaj solvoj postulataj de AppImage en Linukso fariĝas nenecesaj ĉe Hajko, kiu havas la simplecon kaj sofistikecon ĉe sia kerno, kiuj igas ĝin trakti la plej multajn el niaj bezonoj.

Ĉu Hajko bezonas aplikajn pakaĵojn finfine?

Ĉi tio kondukas al granda demando. Se estus multe pli facile krei sistemon kiel AppImage en Hajko ol en Linukso, ĉu indus fari ĝin? Aŭ ĉu Hajko, per sia hpkg-pakaĵsistemo, efike forigis la bezonon evoluigi tian ideon? Nu, por respondi ni devas rigardi la instigon malantaŭ la ekzisto de AppImages.

Perspektivo de uzanto

Ni rigardu nian finuzanton:

• Mi volas instali aplikaĵon sen peti administranton (radikan) pasvorton. Ne ekzistas koncepto de administranto sur Hajku, la uzanto havas plenan kontrolon ĉar ĝi estas persona sistemo! (Principe, vi povas imagi ĉi tion en plurludanta reĝimo, mi esperas, ke la programistoj konservos ĝin simpla)
• Mi volas ricevi la plej novajn kaj plej bonegajn versiojn de aplikaĵoj, sen atendi, ke ili aperos en mia distribuo (plej ofte tio signifas "neniam", almenaŭ se mi ĝisdatigas la tutan operaciumon). Sur Hajko tio estas "solvita" per flosantaj eldonoj. Ĉi tio signifas, ke eblas akiri la plej novajn kaj plej bonegajn versiojn de aplikaĵoj, sed por fari tion, vi devas konstante ĝisdatigi la reston de la sistemo, efike igante ĝin "movanta celo"..
• Mi volas plurajn versiojn de la sama aplikaĵo unu apud la alia, ĉar ne ekzistas maniero scii kio estis rompita en la lasta versio, aŭ, ekzemple, mi, kiel retejo-programisto, devas testi mian laboron sub malsamaj versioj de la retumilo. Hajko solvas la unuan problemon, sed ne la duan. Ĝisdatigoj estas retroigitaj, sed nur por la tuta sistemo; estas neeble (laŭ mi scias) ruli, ekzemple, plurajn versiojn de WebPositive aŭ LibreOffice samtempe.

Unu el la programistoj skribas:

Esence la raciaĵo estas jena: la uzkazo estas tiel malofta ke optimumigo por ĝi ne havas sencon; trakti ĝin kiel specialan kazon en HaikuPorts ŝajnas pli ol akceptebla.

• Mi devas konservi apojn kie mi ŝatas ilin, ne sur mia starta stirado. Mi ofte elĉerpigas diskospacon, do mi bezonas konekti eksteran diskon aŭ retan dosierujon por konservi aplikaĵojn (ĉiuj versioj, kiujn mi elŝutis). Se mi konektas tian stiradon, mi bezonas aplikojn por lanĉi per duobla klako. Hajko konservas malnovajn versiojn de pakaĵoj, sed mi ne scias kiel movi ilin al ekstera disko, aŭ kiel lanĉi aplikaĵojn de tie poste.

Komento de la programisto:

Teknike, ĉi tio jam eblas per la munta komando. Kompreneble, ni faros GUI por ĉi tio tuj kiam ni havos sufiĉe da interesataj uzantoj.

• Mi ne bezonas milionojn da dosieroj disigitaj tra la dosiersistemo, kiujn mi mem ne povas mane administri. Mi volas unu dosieron per aplikaĵo, kiun mi povas facile elŝuti, movi, forigi. Ĉe Hajko ĉi tiu problemo estas solvita per pakaĵoj .hpkg, kiuj transigas, ekzemple, python, de miloj da dosieroj en unu. Sed se ekzistas, ekzemple, Scribus uzanta python, tiam mi devas trakti almenaŭ du dosierojn. Kaj mi devas zorgi konservi versiojn de ili, kiuj funkcias unu kun la alia.

Multoblaj versioj de AppImages funkcias unu apud la alia en la sama Linukso

Perspektivo de programisto de aplikaĵo

Ni rigardu el la vidpunkto de programisto de aplikaĵo:

• Mi volas kontroli la tutan uzantan sperton. Mi ne volas dependi de operaciumo por diri al mi kiam kaj kiel mi devus liberigi aplikaĵojn. Hajko permesas al programistoj labori kun siaj propraj hpkg-deponejoj, sed tio signifas, ke uzantoj devos agordi ilin permane, kio faras la ideon "malpli alloga."
• Mi havas elŝutan paĝon en mia retejo, kie mi distribuas .exe por Vindozo, .dmg por Mac kaj .AppImage por Linukso. Aŭ eble mi volas monetigi aliron al ĉi tiu paĝo, io eblas? Kion mi metu tien por Hajko? La dosiero sufiĉas .hpkg kun dependecoj nur de HaikuPorts
• Mia programaro postulas specifajn versiojn de alia programaro. Ekzemple, estas konata ke Krita postulas flikitan version de Qt, aŭ Qt kiu estas fajnagordita al specifa versio de Krita, almenaŭ ĝis la pecetoj estas puŝitaj reen en Qt. Vi povas paki vian propran Qt por via aplikaĵo en pakaĵo .hpkg, sed plej verŝajne ĉi tio ne estas bonvena.

Regula elŝuta paĝo de aplikaĵo. Kion mi afiŝu ĉi tie por Hajko?

Will pakaĵoj (ekzistantaj kiel aplikaĵaj dosierujoj kiel AppDir aŭ .app Apple-stilo) kaj/aŭ bildoj (en la formo de tre modifitaj AppImages aŭ .dmg de Apple) aplikaĵoj utila aldono al la labortabla medio Haiku? Aŭ ĉu ĝi diluos la tutan bildon kaj kondukos al fragmentiĝo, kaj do aldonos kompleksecon? Mi estas disŝirita: unuflanke, la beleco kaj sofistikeco de Hajko baziĝas sur la fakto ke ekzistas kutime unu maniero fari ion, prefere ol multaj. Aliflanke, la plej granda parto de la infrastrukturo por katalogoj kaj/aŭ aplikaĵaj serioj jam estas en loko, do la sistemo krias, ke la restanta malmultaj procentoj faru lokon.

Laŭ la programisto s-ro. waddlesplash

En Linukso ili (katalogoj kaj aplikaĵoj, - ĉ. tradukisto) estas plej verŝajne teknika solvo al sistemaj problemoj. Ĉe Hajko ni preferas simple solvi sistemajn problemojn.

Kion vi pensas?

Antaŭ ol vi respondos...

Atendu, ni faru rapidan realecan kontrolon: fakte aplikaj dosierujoj - jam parto de Hajko:

Aplikaj dosierujoj jam ekzistas ĉe Hajko, sed ankoraŭ ne estas subtenataj en la dosieradministranto

Ili simple ne estas tiel bone subtenataj kiel ekzemple la Macintosh Finder. Kiom mojose estus se la dosierujo de QtCreator havus nomon kaj ikonon "QtCreator" en la supra maldekstra angulo, lanĉante la aplikaĵon kiam duoble alklaku?

Iom pli frue mi jam demandis:

Ĉu vi certas, ke vi povas ruli viajn dekjarajn aĝajn programojn hodiaŭ, kiam ĉiuj app-vendejoj kaj distribuaj deponejoj forgesis pri ili kaj iliaj dependecoj? Ĉu vi certas, ke vi ankoraŭ povos aliri vian nunan laboron estonte?

Ĉu jam ekzistas respondo de Hajko, aŭ ĉu katalogoj kaj aplikaĵpakaĵoj povas helpi ĉi tie? Mi pensas, ke ili povas.

Laŭ s-ro. waddlesplash:

Jes, ni havas la respondon al la demando: ni simple subtenos ĉi tiujn aplikojn tiel longe kiel necese ĝis iu povas legi siajn dosierformatojn en la ĝusta maniero aŭ disponigi unu-al-unu funkciojn. Nia engaĝiĝo subteni BeOS R5-apojn sur Hajko estas pruvo de tio...

Tiu certas!

Kian agadon hajko devus preni?

Mi povas imagi la pacan kunekzistado de hpkg, dosierujoj kaj aplikaj bildoj:

• Uzoj de sistemaj programoj .hpkg
• Por la plej ofte uzataj programoj (precipe tiuj, kiuj bezonas plani ruliĝantajn eldonojn), uzu .hpkg (ĉirkaŭ 80% de ĉiuj kazoj)
• Iuj instalitaj per .hpkg, aplikoj profitos de translokiĝo al aplikaĵa dosierujo-infrastrukturo (ekz. QtCreator): ili estos distribuitaj kiel .hpkg, kiel antaŭe.

s-ro. waddlesplash skribas:

Se vi bezonas nur vidi aplikojn en /system/apps, anstataŭe ni devas fari la dosierujojn en Deskbar pli regeblaj por uzantoj, ekde /system/apps ne intencas esti regule malfermita kaj rigardata de uzantoj (male al MacOS). Por tiaj situacioj, Hajko havas malsaman paradigmon, sed ĉi tiu opcio estas, en teorio, akceptebla.

• Hajko ricevas la infrastrukturon por ruli aplikajn bildojn, nokte, kontinuajn kaj testajn konstruojn de programaro, same kiel por kazoj kiam la uzanto volas "frostigi ĝin ĝustatempe", por privata kaj interna programaro, kaj aliaj specialaj uzkazoj (ĉirkaŭ 20% de ĉiuj). Ĉi tiuj bildoj enhavas la dosierojn necesajn por ruli la aplikaĵon .hpkg, muntita de la sistemo, kaj post kiam la aplikaĵo estas kompletigita - malmuntita. (Eble dosieradministranto povus meti dosierojn .hpkg en aplikajn bildojn, aŭtomate aŭ laŭ la peto de la uzanto - nu, kiel kiam vi trenas aplikaĵon al retdosierujo aŭ ekstera disko. Ĝi estas nur kanto! Aŭ pli ĝuste, poezio - hajko.) Aliflanke, la uzanto eble volas instali la enhavon de la bildo en formo de dosieroj.hpkg, post kio ili estos ĝisdatigitaj kaj prilaboritaj same kiel se ili estus instalitaj per HaikuDepot... Ni devas cerbumi).

Citaĵo de s-ro. waddlesplash:

Ruli aplikojn de eksteraj diskoj aŭ retaj dosierujoj eble povas esti utila. Kaj aldoni la kapablon agordi pli da "zonoj" por pkgman certe estus bela trajto.

Tia sistemo utiligus hpkg, dosierujojn kaj aplikajn bildojn. Ili estas bonaj individue, sed kune ili fariĝos nevenkeblaj.

konkludo

Hajko havas kadron, kiu provizas simplan kaj altnivelan uzant-sperton por la komputilo, kaj iras multe preter tio, kio estas kutime provizita por la Linuksa komputilo. Paka sistemo .hpkg estas unu tia ekzemplo, sed la resto de la sistemo ankaŭ estas trempita per sofistikeco. Tamen, Hajko profitus de taŭga dosierujo kaj aplika bildo-subteno. Kiel plej bone fari tion indas diskuti kun homoj kiuj konas Hajkon, ĝian filozofion kaj arkitekturon multe pli bone ol mi. Post ĉio, mi uzas hajkon dum iom pli ol semajno. Tamen mi kredas, ke la projektistoj, programistoj kaj arkitektoj de Haiku profitos el ĉi tiu freŝa perspektivo. Almenaŭ, mi ĝojus esti ilia "batala partnero." Mi havas pli ol 10 jarojn da praktika sperto pri katalogoj kaj pakaĵoj de Linuksaj aplikaĵoj, kaj mi ŝatus trovi uzon por ili en Hajko, por kiu mi opinias, ke ili estas perfektaj. La eblaj solvoj, kiujn mi proponis, neniel estas la nuraj ĝustaj por la problemoj, kiujn mi priskribis, kaj se la Haiku-teamo decidas trovi aliajn, pli elegantajn, mi tute favoras. Esence, mi jam pensas pri la ideo de kiel fari sistemon hpkg eĉ pli mirinda sen ŝanĝi la manieron kiel ĝi funkcias. Montriĝas, ke la Haiku-teamo jam delonge pensis pri aplikaĵa pakaĵo dum efektivigo de pakaĵmastruma sistemo, sed bedaŭrinde (mi pensas) la ideo fariĝis "malaktuala". Eble estas tempo revivigi ĝin?

Provu ĝin mem! Post ĉio, la Haiku-projekto provizas bildojn por ekfunkciigo de DVD aŭ USB, generitaj ĉiutaga.
Ĉu vi havas demandojn? Ni invitas vin al la ruslingva telegramkanalo.

Superrigardo de eraroj: Kiel pafi vin en la piedon en C kaj C++. Kolekto de Receptoj de Haiku OS

el la verkisto traduko: jen la oka kaj lasta artikolo de la serio pri Hajko.

Listo de artikoloj: La unua La dua La tria Kvara Kvina Sesa Sepa

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu havas sencon porti la hpkg-sistemon al Linukso?

• Jes

• Neniu

• Jam efektivigita, mi skribos en la komentoj

20 uzantoj voĉdonis. 5 uzantoj sindetenis.

fonto: www.habr.com