TL; DR: Kan Haiku behoorlike ondersteuning kry vir toepassingsbundels, soos toepassingskatalogusse (soos .app op 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.
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 ...
Om heeltemal duidelik te wees: Ek is die skepper en skrywer van AppImage, 'n Linux-toepassingsverspreidingsformaat wat na Mac-eenvoud streef en volle beheer aan toepassingouteurs en eindgebruikers gee (as jy meer wil weet, sien hier). и ).
Wat as ons 'n AppImage vir Haiku maak?
Kom ons praat 'n bietjie, suiwer teoreties, oor wat gedoen moet word om te kry , of iets soortgelyks, op Haiku? Jy hoef nie nou iets te skep nie, want die stelsel wat Haiku reeds het werk ongelooflik, maar 'n denkbeeldige eksperiment sal lekker wees. Dit demonstreer ook die gesofistikeerdheid van Haiku, in vergelyking met Linux-produksie-omgewings, waar sulke dinge verskriklik moeilik is (ek het die reg om so te sê: ek swoeg al vir 10 jaar met ontfouting).
Op die Macintosh System 1 was elke toepassing 'n aparte lêer "bestuur" deur die Finder. Met AppImage probeer ek dieselfde gebruikerservaring op Linux herskep.
Eerstens, wat is 'n AppImage? Dit is 'n stelsel vir die vrystelling van derdeparty-toepassings (byvoorbeeld, ) 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.
AppImage het 'n mate van aantrekkingskrag en gewildheid verkry oor sy meer as 10 jaar van bestaan: Linus Torvalds self het dit in die openbaar onderskryf, en algemene projekte (byvoorbeeld LibreOffice, Krita, Inkscape, Scribus, ImageMagick) het dit as die hoof manier om te versprei aangeneem deurlopende of nagtelike bouwerk, wat nie inmeng met gebruikers se geïnstalleerde of gedeïnstalleerde toepassings nie. Linux-rekenaars en -verspreidings klou egter meestal steeds aan die tradisionele, gesentraliseerde, instandhouer-gebaseerde verspreidingsmodel en/of bevorder hul eie ondernemingbesigheid en/of ingenieursprogramme gebaseer op (RedHat, Fedora, GNOME) en (Kanoniek, Ubuntu). Dit kom .
Hoe werk dit
- Elke AppImage bevat 2 dele: 'n klein dubbelklikbare ELF (aka.
runtime.c), gevolg deur 'n lêerstelselbeeld .
- Die SquashFS-lêerstelsel bevat die loonvrag in die vorm van 'n toepassing en alles wat nodig is om dit te laat loop, wat in goeie sin nie as deel van die verstekinstallasie vir elke redelik onlangse teikenstelsel (Linux-verspreiding) beskou moet word nie. Dit bevat ook metadata, soos die toepassingnaam, ikone, MIME-tipes, ens., 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 soveel verskillende Linux-verspreidings daar buite, kan niks by hul volle verstand "deel van die verstekinstallasie vir elke nuwe teikenstelsel" genoem word nie. Ons kom om hierdie probleem deur te bou , 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 uitvoerLD_LIBRARY_PATHof regmaakrpathsodat 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 AppImage-lêer na aflaai. Glo dit of nie, vir sommige is dit 'n ware hindernis. Die behoefte om die uitvoerbare bietjie in te stel is omslagtig, selfs vir gevorderde gebruikers. As 'n oplossing het ons voorgestel dat 'n klein diens geïnstalleer word wat AppImage-lêers monitor en hul uitvoerbare bit stel. In sy suiwerste vorm, nie die beste oplossing nie, want dit sal nie uit die boks werk nie. Linux-verspreidings verskaf nie hierdie diens nie, so out-of-the-box-gebruikers het 'n moeilike tyd.
- Linux-gebruikers wag vir die nuwe toepassing om 'n ikoon in die bekendstellingskieslys te hê. Jy kan nie vir die stelsel sê: "Kyk, daar is 'n nuwe toepassing, kom ons werk." In plaas daarvan, volgens die XDG-spesifikasie, moet jy die lêer kopieer
.desktopop die regte plek in/usrvir 'n stelselwye installasie, of in$HOMEvir individu. Ikone van sekere groottes, volgens die XDG-spesifikasie, moet op sekere plekke in geplaas wordusrof$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. - As bogenoemde nie genoeg is nie, is daar steeds geen AppImage-ikoon in die lêerbestuurder nie. Die Linux-wêreld het nog nie besluit om elficon te implementeer nie (ten spyte van и ), 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 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.pngmoet oopgemaak word met Krita, en2.png- gebruik GIMP.
Bergplek vir kruis-rekenaarspesifikasies wat gebruik word in , и 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 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 Linux-wêreld van Mac OS X kan leer om nie met stelselintegrasie te mors nie. As jy tyd het en jy doen dit, lees seker wat Arno Gurdol, een van die eerste Mac OS X-ingenieurs, gesê 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.
Apple WWDC 2000 sessie 144 - Mac OS X: verpakking van toepassings en druk van dokumente.
Nie een van hierdie infrastruktuur bestaan op Linux-produksieomgewings nie, so ons soek oplossings vir strukturele beperkings in die AppImage-projek.
Kom Haiku tot die redding?
En nog een ding: Linux-platforms as die basis van lessenaaromgewings is geneig om so ondergespesifiseer te wees dat baie dinge wat redelik eenvoudig is in 'n konsekwente volstapelstelsel frustrerend gefragmenteerd en kompleks in Linux word. Ek het 'n hele praatjie gewy aan kwessies wat verband hou met die Linux-platform vir rekenaaromgewings (kundige ontwikkelaars het bevestig dat dit vir 'n baie lang tyd so sal bly).
My praatjie oor Linux-rekenaarkwessies 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.
Terwyl die naïewe benadering om 'n AppImage na Haiku te "oordra" is om bloot te probeer om sy komponente (basies runtime.c en diens) te probeer bymekaarmaak (wat selfs moontlik kan wees!), sal dit nie veel goed vir Haiku doen nie. Want in werklikheid word die meeste van hierdie probleme op Haiku opgelos en is dit konseptueel gesond. Haiku verskaf presies die soort stelsel-infrastruktuur-boublokke waarna ek al so lank in Linux-desktops gesoek het en kon nie glo dat hulle nie daar was nie. Naamlik:
Glo dit of nie, dit is iets wat baie Linux-gebruikers nie kan oorkom nie. Op 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 asof baie van die krukke en oplossings wat deur AppImage op Linux benodig word, onnodig word op Haiku, wat 'n eenvoud en gesofistikeerdheid in sy kern het wat dit die meeste van ons behoeftes laat hanteer.
Het Haiku tog app-pakkette nodig?
Dit lei tot 'n groot vraag. As dit 'n orde van grootte makliker was om 'n stelsel soos AppImage op Haiku te bou as op Linux, sou dit die moeite werd wees? Of het Haiku, met sy hpkg-verpakkingstelsel, die behoefte om so 'n idee te ontwikkel effektief uitgeskakel? Wel, die antwoord is om te kyk na die motivering agter die bestaan van 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.
Veelvuldige weergawes van AppImages loop langs mekaar op dieselfde 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
.exevir Windows.dmgvir Mac en.AppImagevir Linux. Of wil ek dalk toegang tot hierdie bladsy monetiseer, alles kan wees? Wat moet ek daar plaas vir Haiku? Genoeg lêer.hpkgmet 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
Op Linux is 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 :
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/appsnie 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.hpkgin 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 raamwerk wat 'n eenvoudige en gesofistikeerde gebruikerskoppelvlak vir rekenaars bied, veel verder as wat tipies vir Linux-rekenaars voorsien word. Pakket stelsel .hpkg is een so 'n voorbeeld, maar die res van die stelsel is ook deurspek van sofistikasie. Haiku sal egter baat 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 ken, sy filosofie en argitektuur is baie beter as ek. Ek het uiteindelik Haiku vir net meer as 'n week gebruik. Nietemin glo ek dat hierdie vars voorkoms nuttig sal wees vir die ontwerpers, ontwikkelaars en argitekte van Haiku. Ek sal ten minste bly wees om hul "sparring vennoot." Ek het meer as 10 jaar se praktiese ondervinding met Linux-katalogusse en -bundels en sal graag 'n gebruik daarvoor in Haiku wil vind, waarvoor ek dink hulle is die perfekte konsep. Die potensiële oplossings wat ek voorgestel het, is glad nie die enigste ware vir die probleme wat ek beskryf het nie, en as die Haiku-span besluit om ander, meer elegantes te vind, is ek almal daarvoor. Basies dink ek reeds aan die idee van hoe om 'n 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 .
Het jy vrae? Ons nooi jou uit na die Russiessprekende .
Foutoorsig:
Van Vertaling: Dit is die agtste en laaste artikel in die Haiku-reeks.
Lys van artikels:
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Maak dit sin om die hpkg-stelsel na Linux oor te dra?
-
Ja
-
Geen
-
Reeds geïmplementeer, skryf in die kommentaar
20 gebruikers het gestem. 5 gebruikers het buite stemming gebly.
Bron: will.com