🥇Iets anders: Haiku-toepassingspakkette?

TL; DR: Kan Haiku behoorlike ondersteuning kry vir toepassingsbundels, soos toepassingskatalogusse (soos .app in Mac) en/of toepassingsbeelde (Linux AppImage)? Dit lyk vir my of dit 'n waardige toevoeging sal wees, wat makliker is om korrek te implementeer as in ander stelsels, aangesien die meeste van die infrastruktuur reeds in plek is.

N week gelede Ek het Haiku ontdek, 'n onverwags goeie stelsel. En aangesien ek lankal belangstel in katalogusse en toepassingsbeelde (geïnspireer deur die eenvoud van die Macintosh), is dit nie verbasend dat die idee by my opgekom het nie ...

Terloops, ek is die skepper en outeur van AppImage, 'n toepassingsverspreidingsformaat. Linux, wat daarop gemik is om die Mac eenvoudiger te maak en volledige beheer in die hande van programouteurs en eindgebruikers te plaas (sien meer hieronder). wiki и dokumentasie).

Wat as ons 'n AppImage vir Haiku maak?

Kom ons praat 'n bietjie, suiwer teoreties, oor wat gedoen moet word om te kry AppImage, of iets soortgelyks, op Haiku? Daar is geen nodigheid om nou iets te skep nie, aangesien die stelsel wat Haiku reeds het, wonderlik werk, maar 'n denkbeeldige eksperiment sal lekker wees. Dit demonstreer ook Haiku se gesofistikeerdheid in vergelyking met lessenaaromgewings. Linux, waar sulke dinge verskriklik moeilik is (ek het die reg om dit te sê: ek sukkel al 10 jaar met ontfouting).

Op Macintosh Stelsel 1 was elke toepassing 'n aparte lêer, "bestuur" in die Finder. Deur AppImage te gebruik, probeer ek dieselfde gebruikerservaring herskep op Linux.

Eerstens, wat is 'n AppImage? Dit is 'n stelsel vir die vrystelling van derdeparty-toepassings (byvoorbeeld, Ultimaker Cure) wat jou toelaat om toepassings vry te stel wanneer en hoe hulle wil: nie nodig om die besonderhede van verskeie verspreidings te ken, beleide te bou of infrastruktuur te bou nie, geen behoefte aan onderhouers nie, en hulle vertel nie gebruikers wat (nie) op hul rekenaars geïnstalleer kan word nie . AppImage moet verstaan word as iets soortgelyk aan 'n pakket vir Mac in die formaat .app binne die skyfbeeld .dmg. Die belangrikste verskil is dat die toepassings nie gekopieer word nie, maar altyd binne die AppImage bly, op baie dieselfde manier as Haiku-pakkette .hpkg gemonteer, en nooit in die gewone sin geïnstalleer nie.

Oor sy meer as 10 jaar van bestaan het AppImage 'n mate van vastrapplek en gewildheid verwerf: Linus Torvalds self het dit in die openbaar onderskryf, en gewilde projekte (bv. LibreOffice, Krita, Inkscape, Scribus, ImageMagick) het dit aangeneem as die primêre metode vir die verspreiding van deurlopende of nagtelike bouwerk wat nie inmeng met gebruikers se geïnstalleerde of gedeïnstalleerde toepassings nie. Werkskermomgewings en verspreidings Linux klou meestal steeds vas aan die tradisionele, gesentraliseerde verspreidingsmodel gebaseer op instandhouers en/of bevorder hul eie korporatiewe besigheid en/of ingenieursprogramme gebaseer op Flatpak (RedHat, Fedora, GNOME) en Snappy (Kanonieke, UbuntuDit kom daarheen. belaglik.

Hoe werk dit

Elke AppImage bevat 2 dele: 'n klein dubbelklikbare ELF (aka. runtime.c), gevolg deur 'n lêerstelselbeeld SquashFS.

Die SquashFS-lêerstelsel bevat 'n vrag in die vorm van 'n toepassing en alles wat nodig is om dit te laat loop, wat met 'n gesonde verstand nie as deel van die standaardinstallasie vir elke voldoende onlangse teikenstelsel (verspreiding) beskou kan word nie. LinuxDit bevat ook metadata, soos die toepassingsnaam, ikone, MIME-tipes, ens.

Wanneer dit deur die gebruiker bestuur word, gebruik runtime FUSE en squashfuse om die lêerstelsel te monteer, waarna dit die een of ander toegangspunt (genoem AppRun) binne die gemonteerde AppImage hanteer.
Die lêerstelsel word ontkoppel nadat die proses beëindig is.

Alles blyk eenvoudig te wees.

En hierdie dinge kompliseer dinge:

met so 'n verskeidenheid verspreidings Linux Niks wat 'n mens in sy volle verstand het, kan meer "deel van die standaardinstallasie vir elke nuwe teikenstelsel" genoem word nie. Ons omseil hierdie probleem deur te bou uitsluitlys, wat jou toelaat om te bepaal wat in die AppImage verpak sal word en wat iewers anders geneem moet word. Terselfdertyd mis ons soms, ondanks die feit dat alles oor die algemeen goed werk. Om hierdie rede beveel ons aan dat verpakkers AppImages op alle teikenstelsels (verspreidings) toets.
Loonvragtoepassings moet lêerstelsel-swerfbaar wees. Ongelukkig het baie toepassings hardgekodeerde absolute paaie na byvoorbeeld hulpbronne in /usr/share. Dit moet op een of ander manier reggestel word. Daarbenewens moet jy óf uitvoer LD_LIBRARY_PATHof regmaak rpath sodat die laaier die geassosieerde biblioteke kan vind. Die eerste metode het sy nadele (wat op komplekse maniere bestuur word), en die tweede is net omslagtig.
Die grootste UX-val vir gebruikers is wat hulle nodig het stel uitvoerbare bietjie AppImage-lêer na aflaai. Glo dit of nie, dit is 'n ware hindernis vir sommige. Die instelling van die uitvoerbare bit is selfs vir ervare gebruikers omslagtig. As 'n tydelike oplossing het ons voorgestel dat ons 'n klein diens installeer wat AppImage-lêers monitor en hul uitvoerbare bit stel. In sy suiwer vorm is dit nie die beste oplossing nie, aangesien dit nie uit die boks sal werk nie. Verspreidings Linux Hulle bied nie hierdie diens nie, so die gebruikers het 'n slegte ervaring uit die boks.
Lede Linux Hulle verwag dat 'n nuwe toepassing 'n ikoon in die lanseerder sal hê. Jy kan nie net vir die stelsel sê: "Kyk, daar's 'n nuwe toepassing, kom ons begin nie." In plaas daarvan, volgens die XDG-spesifikasie, moet jy die lêer kopieer. .desktop op die regte plek in /usr vir 'n stelselwye installasie, of in $HOME vir individu. Ikone van sekere groottes, volgens die XDG-spesifikasie, moet op sekere plekke in geplaas word usr of $HOME, voer dan opdragte in die lessenaar uit om die ikoonkas op te dateer, of hoop dat die lessenaarbestuurder dit sal uitvind en alles outomaties sal opspoor. Net so met MIME-tipes. As 'n oplossing word voorgestel om dieselfde diens te gebruik, wat benewens die stel van die haalbaarheidsvlag sal wees, as daar ikone ensovoorts is. in AppImage, kopieer hulle van AppImage na die regte plekke volgens XDG. Wanneer dit uitgevee of geskuif word, sal die diens glo alles skoonmaak. Natuurlik is daar verskille in die gedrag van elke werksomgewing, in die formate van grafiese lêers, hul groottes, stoorplekke en hoe kas opgedateer word, wat 'n probleem skep. Kortom, hierdie metode is 'n kruk.
Asof dit nie genoeg was nie, is daar steeds geen AppImage-ikoon in die lêerbestuurder nie. Linux het nog steeds nie 'n besluit geneem oor die implementering van elficon nie (ten spyte van bespreking и implementering), dus is dit nie moontlik om die ikoon direk in die toepassing in te sluit nie. Dit blyk dus dat toepassings in die lêerbestuurder nie hul eie ikone het nie (geen verskil, AppImage of iets anders nie), dit is slegs in die bekendstellingskieslys. As 'n oplossing gebruik ons duimnaels, 'n meganisme wat oorspronklik ontwerp is om rekenaarbestuurders toe te laat om duimnaelvoorskoue van grafiese lêers as hul ikone te vertoon. Daarom werk die diens vir die opstel van die uitvoerbare bietjie ook as 'n "verdunner", wat ikoon-kleinkiekies op die toepaslike plekke skep en skryf. /usr и $HOME. Dit maak ook skoon as die AppImage uitgevee of geskuif word. Omdat elke rekenaarbestuurder effens anders optree, soos in watter formate dit ikone aanvaar, watter groottes of liggings, is dit alles baie pynlik.
Die toepassing crash eenvoudig tydens looptyd as foute voorkom (daar is byvoorbeeld 'n biblioteek wat nie deel van die basisstelsel is nie en nie deur AppImage verskaf word nie), en niemand vertel die gebruiker in die GUI wat presies aangaan nie. Ons het dit begin omseil deur te gebruik kennisgewings op die lessenaar, wat beteken dat ons foute van die opdragreël moet opvang, dit omskep in gebruikersvriendelike boodskappe, wat dan op die lessenaar vertoon moet word. En natuurlik hanteer elke lessenaaromgewing dit 'n bietjie anders.
Op die oomblik (September 2019 - vertaler se nota), het ek nie 'n maklike manier gevind om die stelsel te vertel dat die lêer nie 1.png moet oopgemaak word met Krita, en 2.png - gebruik GIMP.

Bergplek vir kruis-rekenaarspesifikasies wat gebruik word in GNOME, KDE и Xfce is freedesktop.org

Om die vlak van gesofistikeerdheid te bereik wat diep in die Haiku-lessenaaromgewing geweef is, is moeilik, indien nie onmoontlik nie, weens die spesifikasies XDG van freedesktop.org vir kruis-lessenaar, sowel as implementering van rekenaarbestuurders gebaseer op hierdie spesifikasies. As voorbeeld kan een stelselwye Firefox-ikoon aangehaal word: blykbaar het die skrywers van XDG nie eers gedink dat 'n gebruiker verskeie weergawes van dieselfde toepassing kan hê nie.

Ikone vir verskillende weergawes van Firefox

Ek het gewonder wat die wêreld was Linux Ek kan by Mac OS X leer om te verhoed dat ek stelselintegrasie bederf. As jy die tyd het en hierby betrokke is, lees gerus wat Arnaud Gourdold, een van die eerste Mac OS X-ingenieurs, te sê gehad het:

Ons wou die installering van die toepassing so maklik maak soos om die toepassingsikoon van enige plek (bediener, eksterne skyf) na u rekenaar se skyf te sleep. Om dit te doen, stoor die toepassingspakket al die inligting, insluitend ikone, weergawe, lêertipe verwerk, URL-skematipe, wat die stelsel moet ken om die toepassing te verwerk. Dit sluit ook inligting vir 'sentrale berging' in die Icon Services en Launch Services databasis in. Om prestasie te ondersteun, word toepassings op verskeie 'welbekende' plekke 'ontdek': in die stelsel en gebruiker se toepassingsgids, en in sommige ander outomaties as die gebruiker die Finder na die gids wat die toepassing bevat, navigeer. In die praktyk het dit baie goed gewerk.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sessie 144 - Mac OS X: verpakking van toepassings en druk van dokumente.

Daar is niks soortgelyks van hierdie infrastruktuur in produksieomgewings nie. Linux, so ons soek na oplossings vir die strukturele beperkings in die AppImage-projek.

Kom Haiku tot die redding?

En ook: platforms Linux as die basis van werksomgewings, is tipies so ondergespesifiseer dat baie dinge wat redelik eenvoudig in 'n samehangende volstapelstelsel sou wees, frustrerend gefragmenteerd en kompleks raak in LinuxEk het 'n hele verslag gewy aan kwessies wat verband hou met die platform. Linux vir werksomgewings (kundige ontwikkelaars het bevestig dat alles vir 'n baie lang tyd so sal bly).

My verslag oor die probleme van werksomgewings Linux in 2018

Selfs Linus Torvalds het erken dat dit weens die fragmentasie was dat die idee van werksomgewings misluk het.

Goed om Haiku te sien!

Met Haiku word alles ongelooflik eenvoudig.

Alhoewel 'n naïewe benadering tot die "oordrag" van AppImage na Haiku sou wees om bloot te probeer om die komponente daarvan (hoofsaaklik runtime.c en die diens) saam te stel (wat dalk selfs moontlik is!), sou dit nie veel voordeel vir Haiku inhou nie. Want in werklikheid word die meeste van hierdie probleme in Haiku opgelos en is konseptueel gesond. Haiku bied presies die boustene vir die stelselinfrastruktuur waarna ek al so lank in lessenaaromgewings soek. Linux en kon nie glo dat hulle nie daar was nie. Naamlik:

Glo dit of nie, baie gebruikers kan dit nie oorkom nie. LinuxOp Haiku word alles outomaties gedoen!

ELF-lêers wat nie 'n uitvoerbare bis het nie, kry dit outomaties wanneer u in die lêerbestuurder dubbelklik.
Toepassings kan ingebedde hulpbronne hê, soos ikone wat in die lêerbestuurder verskyn. Jy hoef nie 'n klomp prente na spesiale ikoongidse te kopieer nie, en hoef dit dus nie skoon te maak nadat jy 'n toepassing uitgevee of geskuif het nie.
Daar is 'n databasis om toepassings aan dokumente te koppel, dit is nie nodig om enige lêers hiervoor te kopieer nie.
In die lib/-gids langs die uitvoerbare lêer word biblioteke by verstek gesoek.
Daar is geen veelvuldige verspreidings en lessenaaromgewings nie, alles wat werk, werk oral.
Daar is geen aparte module om uit te voer wat verskil van die toepassingsgids nie.
Toepassings het nie ingeboude absolute paaie na hul hulpbronne nie, daar is spesiale funksies om die ligging tydens looptyd te bepaal.
Het die idee van saamgeperste lêerstelselbeelde bekendgestel: enige hpkg-pakket. Hulle word almal deur die kern gemonteer.
Elke lêer word oopgemaak deur die toepassing wat dit geskep het, tensy anders gespesifiseer. Hoe cool is dit nie!

Twee png-lêers. Gee aandag aan die verskillende ikone wat wys dat hulle deur verskillende toepassings oopgemaak sal word wanneer u dubbelklik. Let ook op die "Maak oop met:" aftreklys waar die gebruiker 'n individuele toepassing kan kies. Hoe eenvoudig!

Dit lyk soos baie van die hacks en oplossings wat AppImage benodig op Linux, word onnodig op Haiku, wat in sy kern 'n eenvoud en gesofistikeerdheid het wat dit geskik maak vir die meeste van ons behoeftes.

Het Haiku tog app-pakkette nodig?

Dit bring my by die groot vraag: As die skep van 'n stelsel soos AppImage op Haiku 'n orde van grootte makliker was as op Linux, sou dit die moeite werd wees om na te streef? Of het Haiku, met sy hpkg-verpakkingstelsel, die behoefte aan so 'n idee effektief uitgeskakel? Wel, om dit te beantwoord, moet ons kyk na die motivering agter AppImages.

Gebruikersperspektief

Kom ons kyk na ons eindgebruiker:

Ek wil 'n toepassing installeer sonder om 'n administrateur (wortel) wagwoord te vra. Daar is geen konsep van 'n administrateur op Haiku nie, die gebruiker het volle beheer omdat dit 'n persoonlike stelsel is! (In beginsel kan jy jou dit in multiplayer-modus voorstel, ek hoop die ontwikkelaars hou dit eenvoudig)
Ek wil die nuutste en beste weergawes van toepassings kry, nie wag dat hulle in my verspreiding verskyn nie (meestal beteken dit "nooit", ten minste as jy nie die hele bedryfstelsel opdateer nie). Op Haiku word dit "opgelos" met drywende vrystellings. Dit beteken dat dit moontlik is om die nuutste en beste weergawes van toepassings te kry, maar hiervoor moet u die res van die stelsel voortdurend bywerk, om dit in 'n "bewegende teiken" te verander..
Ek wil veelvuldige weergawes van dieselfde toepassing langs mekaar hê, want ek kan nie uitvind wat in die nuutste weergawe gebreek is nie, of, kom ons sê, as 'n webontwikkelaar moet ek my werk onder verskillende blaaierweergawes nagaan. Haiku los die eerste probleem op, maar nie die tweede nie. Opdaterings word teruggerol, maar slegs vir die hele stelsel is dit onmoontlik (sover ek weet) om byvoorbeeld verskeie weergawes van WebPositive of LibreOffice op dieselfde tyd te laat loop.

Een van die ontwikkelaars skryf:

In wese is die rasionaal dit: 'n gebruiksgeval is so skaars dat dit geen sin maak om daarvoor te optimaliseer nie; om dit as 'n spesiale geval in HaikuPorts te hanteer, lyk meer as aanvaarbaar.

Ek moet toepassings stoor waar ek wil, nie op my opstartskyf nie. Ek het dikwels min spasie op skywe, so ek moet 'n eksterne skyf of 'n netwerkgids koppel om toepassings te stoor (alle weergawes wat ek afgelaai het). As ek so 'n skyf koppel, is dit nodig dat toepassings geloods word deur te dubbelklik. Haiku hou ou weergawes van pakkette, maar ek weet nie hoe om dit na 'n eksterne skyf te skuif nie, en ook hoe om toepassings later daarvandaan te bel nie.

Ontwikkelaar se opmerking:

Tegnies is dit reeds moontlik met die berg-opdrag. Natuurlik sal ons 'n GUI hiervoor maak sodra daar genoeg belangstellende gebruikers is.

Ek het nie miljoene lêers wat oor die lêerstelsel versprei is nodig wat ek nie self met die hand kan bestuur nie. Ek wil een lêer per toepassing hê wat ek maklik kan aflaai, skuif, uitvee. Op Haiku word hierdie probleem met pakkette opgelos .hpkg, wat byvoorbeeld python van duisende lêers na een oordra. Maar as daar byvoorbeeld Scribus is wat python gebruik, dan moet ek met ten minste twee lêers hanteer. En ek moet sorg dat ek weergawes daarvan hou wat met mekaar werk.

Verskeie weergawes van AppImages loop langs mekaar op een Linux

App Ontwikkelaar se perspektief

Kom ons kyk vanuit 'n toepassingsontwikkelaar se oogpunt:

Ek wil die hele gebruikerservaring bestuur. Ek wil nie van 'n bedryfstelsel staatmaak om vir my te sê wanneer en hoe ek programme moet vrystel nie. In Haiku kan ontwikkelaars met hul eie hpkg-bewaarplekke werk, maar dit beteken dat gebruikers dit handmatig sal moet konfigureer, wat hierdie idee "minder aantreklik" maak.
Ek het 'n aflaai bladsy op my webwerf waar ek versprei .exe vir Windows, .dmg vir Mac en .AppImage vir LinuxOf wil ek dalk toegang tot hierdie bladsy monetiseer? Enigiets is moontlik? Wat moet ek daar vir Haiku plaas? Genoeg lêer .hpkg met afhanklikhede slegs op HaikuPorts
My sagteware benodig spesifieke weergawes van ander sagteware. Dit is byvoorbeeld bekend dat Krita 'n gelapte weergawe van Qt nodig het, of Qt wat fyn ingestel is op 'n spesifieke weergawe van Krita, ten minste totdat die pleisters in Qt teruggedruk word. Dit is moontlik om oorspronklike Qt vir 'n toepassing in 'n pakket te verpak .hpkg, maar dit is heel waarskynlik nie welkom nie.

Die gewone app aflaai bladsy. Wat om hier te plaas vir Haiku?

Sal-bundels (dié wat bestaan as app-gidse soos AppDir of .app in die styl van Apple) en/of beelde (in die vorm van sterk gewysigde AppImages of .dmg van Apple) toepassings 'n nuttige toevoeging tot die Haiku-werkomgewing? Of sal dit die hele prentjie verwater en tot fragmentasie lei, en dus kompleksiteit byvoeg? Ek is verskeur: aan die een kant is die skoonheid en sofistikasie van Haiku gebaseer op die feit dat daar gewoonlik een manier is om iets te doen, nie baie nie. Aan die ander kant is die meeste van die infrastruktuur vir katalogusse en/of app-bundels reeds in plek, so die stelsel skree uit vir die oorblywende paar persent om in plek te val.

Volgens die ontwikkelaar Mnr. waddleplash

Op Linux Hulle (katalogusse en toepassingsbundels, - ongeveer. vertaler) is heel waarskynlik 'n tegniese oplossing vir sistemiese probleme. By Haiku verkies ons om bloot sistemiese probleme op te los.

Wat dink jy?

Voor jy antwoord...

Wag, kom ons doen 'n vinnige werklikheidskontrole: om die waarheid te sê toepassingsgidse - reeds deel van Haiku:

Toepassingsgidse bestaan reeds op Haiku, maar word nog nie in die lêerbestuurder ondersteun nie

Hulle word net nie so goed ondersteun soos byvoorbeeld die Macintosh Finder nie. Hoe gaaf sou dit wees as die QtCreator-gids die naam en ikoon "QtCreator" in die linkerbovenhoek het, wat die toepassing met dubbelklik begin?

'n Bietjie vroeër het ek gevra:

Is jy seker jy sal jou dekade-oue toepassings vandag bekendstel, wanneer al die toepassingswinkels en verspreidingsbewaarplekke van hulle en hul afhanklikhede vergeet het? Is jy seker jy sal in die toekoms steeds toegang tot jou huidige werk kry?

Is daar reeds 'n antwoord van Haiku, of kan katalogusse en app-bundels hier help? Ek dink hulle kan.

Volgens mnr. waddleplash:

Ja, ons het 'n antwoord op die vraag: ons sal hierdie toepassings net ondersteun so lank as wat nodig is totdat iemand hul lêerformate op die regte manier kan lees of een-tot-een-funksionaliteit kan verskaf. Ons verbintenis om BeOS R5-toepassings op Haiku te laat loop, is 'n bewys daarvan ...

Dit is vir seker!

Watter optrede moet Haiku neem?

Ek kan my die vreedsame naasbestaan van hpkg, gidse en toepassingsbeelde voorstel:

Die stelsel sagteware gebruik .hpkg
Vir die sagteware wat die meeste gebruik word (veral die een wat vir rollende vrystellings geskeduleer moet word), gebruik .hpkg (ongeveer 80% van alle gevalle)
Sommige geïnstalleer deur .hpkg, sal toepassings baat by die skuif na 'n toepassingskatalogus-infrastruktuur (bv. QtCreator): hulle sal versprei word as .hpkg, soos voorheen.

Mnr. waddlesplash skryf:

As al wat jy nodig het, is om programme in te blaai /system/apps, maak eerder die gidse in Deskbar meer hanteerbaar vir gebruikers, want /system/apps nie ontwerp vir gebruikers om dit gereeld oop te maak en te kyk nie (anders as macOS). Vir sulke situasies het Haiku 'n ander paradigma, maar hierdie opsie is in teorie aanvaarbaar.

Haiku kry die infrastruktuur om toepassingsbeelde te laat loop, nagtelike, deurlopende en toetsbou van sagteware, sowel as wanneer die gebruiker dit wil "betyds vries", vir eie en interne sagteware, en ander spesiale gebruiksgevalle (ongeveer 20% van alle ). Hierdie beelde bevat die lêers wat nodig is om die toepassing te laat loop. .hpkg, gemonteer deur die stelselgereedskap, en na die einde van die toepassing - ontkoppel. (Miskien kan 'n lêerbestuurder lêers plaas .hpkg in toepassingsbeelde, outomaties of op versoek van die gebruiker - wel, soos wanneer u 'n toepassing na 'n netwerkgids of 'n eksterne skyf sleep. Dis net 'n liedjie! Of eerder, poësie - haikoe.) Aan die ander kant wil die gebruiker dalk die inhoud van die prent in die vorm van lêers installeer.hpkg, waarna hulle op dieselfde manier opgedateer en verwerk sal word asof hulle deur HaikuDepot geïnstalleer is ... Moet dinkskrum).

Aanhaling van mnr. waddlesplash:

Die bekendstelling van toepassings vanaf eksterne aandrywers of netwerkgidse kan moontlik nuttig wees. En om die vermoë by te voeg om meer "sones" vir pkgman te konfigureer, sal beslis 'n goeie kenmerk wees.

So 'n stelsel sal voordeel trek uit hpkg, katalogusse en toepassingsbeelde. Hulle is individueel goed, maar saam sal hulle onoorwinlik wees.

Gevolgtrekking

Haiku het 'n infrastruktuur wat 'n eenvoudige en gesofistikeerde gebruikerskoppelvlak vir rekenaars bied, en gaan veel verder as wat tipies vir rekenaars op ... verskaf word. LinuxPakketstelsel .hpkg — is een so 'n voorbeeld, maar ander dele van die stelsel is ook deurdrenk met gesofistikeerdheid. Haiku sal egter baat vind by behoorlike ondersteuning vir toepassingskatalogusse en -beelde. Hoe om dit die beste te doen, is die moeite werd om te bespreek met mense wat Haiku, sy filosofie en argitektuur baie beter ken as ek. Ek gebruik immers Haiku nou net vir 'n bietjie meer as 'n week. Nietemin glo ek dat hierdie vars perspektief nuttig sal wees vir Haiku se ontwerpers, ontwikkelaars en argitekte. Ten minste sal ek bly wees om 'n "sparringpartner" vir hulle te wees. Ek het meer as 10 jaar praktiese ervaring met toepassingskatalogusse en beeldbundels vir Linux, en ek wil graag 'n gebruik daarvoor in Haiku vind, waarvoor ek glo hulle 'n perfekte pasmaat is. Die potensiële oplossings wat ek voorgestel het, is nie die enigstes vir die probleme wat ek beskryf het nie, en as die Haiku-span besluit om ander, meer elegante oplossings te vind, is ek heeltemal daarvoor. In beginsel dink ek reeds aan 'n idee vir hoe om die stelsel te maak. hpkg selfs meer ongelooflik sonder om die manier waarop dit werk te verander. Dit blyk dat die Haiku-span al lank aan app-bundels dink wanneer hulle 'n pakketbestuurstelsel implementeer, maar ongelukkig (dink ek) het die idee "uitgedien" geraak. Miskien is dit tyd om dit te laat herleef?

Probeer dit self! Die Haiku-projek verskaf immers beelde vir selflaai vanaf DVD of USB, gegenereer daaglikse.
Het jy vrae? Ons nooi jou uit na die Russiessprekende telegramkanaal.

Foutoorsig: Hoe om jouself in die voet te skiet in C en C++. Haiku OS-resepteversameling

Van die skrywer Vertaling: Dit is die agtste en laaste artikel in die Haiku-reeks.

Lys van artikels: Eerste Die tweede Третья Vierde Die vyfde Sesde sewende

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.