TL; DR: Kin Haiku juste stipe krije foar applikaasjepakketten, lykas applikaasje-mappen (lykas .app op Mac) en/of applikaasjeôfbyldings (Linux AppImage)? Ik tink dat dit in weardige oanfolling soe wêze dy't makliker is korrekt te ymplementearjen dan oare systemen, om't de measte ynfrastruktuer al yn plak is.
Ik ûntduts Haiku, in ûnferwachts goed systeem. No, om't ik al lang ynteressearre wie yn mappen en applikaasjeôfbyldings (ynspirearre troch de ienfâld fan 'e Macintosh), is it net ferrassend dat in idee yn myn tinzen kaam ...
Foar folslein begryp bin ik de skepper en skriuwer fan AppImage, in Linux-applikaasjedistribúsjeformaat dat rjochte is op Mac-ienfâld en folsleine kontrôle jout oan applikaasje-auteurs en ein brûkers (as jo mear witte wolle, sjoch и ).
Wat as wy in AppImage meitsje foar Haiku?
Lit ús in bytsje tinke, suver teoretysk: wat moat der dien wurde om te krijen , of sokssawat, op Haiku? It is net nedich om no wat te meitsjen, want it systeem dat al bestiet yn Haiku wurket geweldich, mar in tinkbyldich eksperimint soe moai wêze. It toant ek de ferfining fan Haiku, yn ferliking mei Linux-buroblêdomjouwings, wêr't sokke dingen ferskriklik lestich binne (ik haw it rjocht om dat te sizzen: ik haw 10 jier muoite mei debuggen).
Op it Macintosh System 1 wie elke applikaasje in apart bestân "beheard" yn 'e Finder. Mei AppImage besykje ik deselde brûkersûnderfining op Linux opnij te meitsjen.
As earste, wat is in AppImage? Dit is in systeem foar it frijjaan fan applikaasjes fan tredden (bygelyks, ), wêrtroch applikaasjes kinne wurde frijjûn wannear en hoe't se wolle: d'r is gjin need om de spesifiken fan ferskate distribúsjes te witten, belied te bouwen of ynfrastruktuer te bouwen, gjin ûnderhâldsstipe is nedich, en se fertelle brûkers net wat (net) se kinne ynstallearje op harren kompjûters. AppImage moat wurde begrepen as iets dat liket op in Mac-pakket yn it formaat .app binnen de skiifôfbylding .dmg. It wichtichste ferskil is dat applikaasjes net kopiearre wurde, mar foar altyd binnen de AppImage bliuwe, sawat itselde as Haiku-pakketten .hpkg mounted, en nea ynstallearre yn 'e gewoane sin.
Yn 'e rin fan mear as 10 jier fan bestean hat AppImage wat oantrekking en populariteit krigen: Linus Torvalds sels ûndersocht it iepenbier, en mienskiplike projekten (bygelyks LibreOffice, Krita, Inkscape, Scribus, ImageMagick) hawwe it oannommen as de wichtichste manier om trochgeande of nachtlike builds te fersprieden, net bemuoie mei ynstalleare of net-ynstalleare brûkersapplikaasjes. Linux-buroblêdomjouwings en -distribúsjes hâlde lykwols meastentiids noch fêst oan it tradisjonele, sintralisearre op ûnderhâlder basearre distribúsjemodel en/of befoarderje har eigen bedriuwsbedriuw en/of engineeringprogramma's basearre op (RedHat, Fedora, GNOME) en (Canonical, Ubuntu). It komt .
Hoe wurket it
- Elts AppImage befettet 2 dielen: in lytse dûbele-klik ELF (saneamde.
runtime.c), folge troch in triemsysteemôfbylding .
- It SquashFS-bestânsysteem befettet de loadload fan 'e applikaasje en alles dat nedich is om it út te fieren, dy't yn' e goeie geast net kin wurde beskôge as diel fan 'e standertynstallaasje foar elk frij resint doelsysteem (Linux-distribúsje). It befettet ek metadata, lykas de applikaasjenamme, ikoanen, MIME-typen, ensfh., ensfh.
- Wannear't rinne troch de brûker, runtime brûkt FUSE en squashfuse te mount it triemsysteem, en dan behannelet it rinnen fan guon yngongspunt (aka AppRun) binnen de monteard AppImage.
It bestânsysteem wurdt unmounted nei it proses foltôge.
Alles liket ienfâldich.
En dizze dingen komplisearje alles:
- Mei sa'n ferskaat oan Linux-distribúsjes kin neat "yn 'e goede geast" wurde neamd "diel fan 'e standertynstallaasje foar elk nij doelsysteem." Wy wurkje om dit probleem troch te bouwen , wêrtroch jo kinne bepale wat yn 'e AppImage ferpakt wurde sil en wat earne oars nommen wurde moat. Tagelyk misse wy soms, nettsjinsteande it feit dat yn 't algemien alles geweldich wurket. Om dizze reden riede wy oan dat makkers fan pakketten AppImages testen op alle doelsystemen (distribúsjes).
- Applikaasje loadloads moatte ferpleatst wurde oer it bestânsysteem. Spitigernôch hawwe in protte applikaasjes hurdkodearre absolute paden nei bygelyks boarnen yn
/usr/share. Dit moat op ien of oare manier fêstlein wurde. Derneist moatte jo ek eksportearjeLD_LIBRARY_PATH, of reparearjerpathsadat de loader relatearre biblioteken kin fine. De earste metoade hat syn neidielen (dy't wurde oerwûn yn komplekse manieren), en de twadde is gewoan omslachtig. - De grutste UX-pitfal foar brûkers is dat AppImage-bestân nei it ynladen. Leau it of net, dit is in echte barriêre foar guon. De needsaak om it útfierberensbit yn te stellen is omslachtich sels foar betûfte brûkers. As oplossing stelden wy foar it ynstallearjen fan in lytse tsjinst dy't AppImage-bestannen kontrolearret en har útfierberensbit ynstelt. Yn syn suvere foarm is it net de bêste oplossing, om't it net út 'e doaze sil wurkje. Linux-distribúsjes leverje dizze tsjinst net, dêrom hawwe brûkers in minne ûnderfining bûten it fak.
- Linux-brûkers ferwachtsje dat in nije applikaasje in ikoan hat yn it opstartmenu. Jo kinne it systeem net fertelle: "Sjoch, d'r is in nije applikaasje, lit ús wurkje." Ynstee, neffens de XDG-spesifikaasje, moatte jo it bestân kopiearje
.desktopnei it goede plak yn/usrfoar in systeem-wide ynstallaasje, of yn$HOMEfoar yndividuele. Ikoanen fan bepaalde maten, neffens de XDG-spesifikaasje, moatte wurde pleatst op bepaalde plakken ynusrof$HOME, en dan kommando's útfiere yn 'e wurkomjouwing om it byldkaike-cache te aktualisearjen, of hoopje dat de wurkomjouwingsbehearder it útfine sil en alles automatysk ûntdekt. Itselde mei MIME-typen. As oplossing wurdt foarsteld om deselde tsjinst te brûken, dy't, neist it ynstellen fan de útfierberensflagge, sil, as d'r ikoanen binne, ensfh. yn AppImage, kopiearje se fan AppImage nei de juste plakken neffens XDG. Wannear't wiske of ferpleatst wurdt, wurdt ferwachte dat de tsjinst alles wiskje sil. Fansels binne d'r ferskillen yn it gedrach fan elke wurkomjouwing, yn grafyske bestânsformaten, har grutte, opslachlokaasjes en metoaden foar it bywurkjen fan caches, wat in probleem makket. Koartsein, dizze metoade is in kruk. - As it boppesteande net genôch is, is d'r noch gjin AppImage-ikoan yn 'e triembehearder. De Linux-wrâld hat noch net besletten om elficon te ymplementearjen (nettsjinsteande и ), dus it is ûnmooglik om it ikoan direkt yn 'e applikaasje yn te foegjen. Sa docht bliken dat applikaasjes yn 'e triembehearder gjin eigen ikoanen hawwe (gjin ferskil, AppImage of wat oars), se binne allinich yn it startmenu. As oplossing brûke wy thumbnails, in meganisme dat oarspronklik is ûntworpen om buroblêdbehearders thumbnailfoarbyldôfbyldings fan grafyske bestannen as har ikoanen te sjen litte. Dêrtroch wurket de tsjinst foar it ynstellen fan it útfierberensbit ek as in "miniaturizer", it meitsjen en skriuwen fan byldkaikes nei de passende lokaasjes
/usrи$HOME. Dizze tsjinst docht ek skjinmeitsjen as de AppImage wurdt wiske of ferpleatst. Fanwegen it feit dat elke buroblêdbehearder wat oars gedraacht, bygelyks yn hokker formaten it ikoanen akseptearret, yn hokker maten of plakken, is dit allegear echt pynlik. - De applikaasje crasht gewoan by útfiering as flaters foarkomme (Bygelyks is d'r in bibleteek dy't gjin diel is fan it basissysteem en wurdt net levere yn AppImage), en d'r is gjinien dy't de brûker yn 'e GUI fertelt wat der krekt bart. Wy begûnen om dit te krijen troch te brûken op it buroblêd, wat betsjut dat wy moatte fange flaters út de kommandorigel, omsette se yn berjochten begryplik foar de brûker, dy't dan moatte wurde werjûn op it buroblêd. En fansels behannelet elke buroblêdomjouwing se in bytsje oars.
- Op it stuit (septimber 2019 - oersetternotysje) haw ik gjin ienfâldige manier fûn om it systeem te fertellen dat it bestân
1.pngmoat wurde iepene mei Krita, en2.png- mei help fan GIMP.
Opslachlokaasje foar cross-desktop spesifikaasjes brûkt yn , и is freedesktop.org
It berikken fan it nivo fan ferfining djip weefd yn 'e Haiku-wurkomjouwing is lestich, as net ûnmooglik, fanwege de spesifikaasjes foar cross-desktop, lykas ymplemintaasjes fan buroblêdbehearders basearre op dizze spesifikaasjes. As foarbyld kinne wy ien systeemwiid Firefox-ikoan neame: blykber tochten de auteurs fan XDG net iens dat in brûker ferskate ferzjes fan deselde applikaasje ynstalleare koe.
Ikoanen foar ferskate ferzjes fan Firefox
Ik frege my ôf wat de Linux-wrâld koe leare fan Mac OS X om systeemyntegraasje te foarkommen. As jo tiid hawwe en dit binne, lês dan wat Arnaud Gurdol, ien fan 'e earste Mac OS X-yngenieurs, sei:
Wy woenen it ynstallearjen fan de applikaasje sa maklik meitsje as it slepen fan it applikaasje-ikoan fan earne (tsjinner, eksterne skiif) nei jo kompjûterstasjon. Om dit te dwaan, bewarret it applikaasjepakket alle ynformaasje, ynklusyf ikoanen, ferzje, triemtype dat wurdt ferwurke, type URL-skema's dat it systeem moat witte om de applikaasje te ferwurkjen. Dit omfettet ek ynformaasje foar 'sintrale opslach' yn 'e Icon Services en Launch Services databank. Om prestaasjes te stypjen, wurde applikaasjes 'ûntdutsen' op ferskate 'bekende' plakken: it systeem- en brûker-applikaasjemappen, en guon oaren automatysk as de brûker nei de Finder navigearret yn 'e map mei de applikaasje. Yn de praktyk wurke dit hiel goed.
Apple WWDC 2000 sesje 144 - Mac OS X: ferpakkingsapplikaasjes en printsjen fan dokuminten.
D'r is neat as dizze ynfrastruktuer op Linux-buroblêden, dus wy sykje nei oplossingen om de strukturele beheiningen yn it AppImage-projekt.
Komt Haiku te rêden?
En noch ien ding: Linux-platfoarms as de basis fan buroblêd-omjouwings hawwe de neiging sa ûnderspesifisearre te wêzen dat in protte dingen dy't frij ienfâldich binne yn in konsistint full-stack-systeem frustrerend fragminteare en kompleks binne yn Linux. Ik wijd in folslein rapport oan problemen yn ferbân mei it Linux-platfoarm foar buroblêd-omjouwings (wittenskipbere ûntwikkelders befêstige dat alles dizze manier foar in heul lange tiid sil bliuwe).
Myn rapport oer de problemen fan Linux-buroblêdomjouwings yn 2018
Sels Linus Torvalds joech ta dat fragmintaasje wie wêrom it idee fan 'e wurkromte mislearre.
Leuk om Haiku te sjen!
Haiku makket alles verbazingwekkend ienfâldich
Wylst de naïve oanpak foar it "portearjen" fan AppImage nei Haiku is om gewoan te besykjen te bouwen (benammen runtime.c en tsjinst) syn komponinten (wat sels mooglik is!), Dit sil net folle foardiel foar Haiku leverje. Om't feitlik de measte fan dizze problemen wurde oplost yn Haiku en binne konseptueel lûd. Haiku leveret krekt de systeemynfrastruktuerboublokken wêr't ik sa lang nei socht ha yn Linux-buroblêdomjouwings en net koe leauwe dat d'r net wiene. Nammentlik:
Leau it of net, dit is iets dat in protte Linux-brûkers net kinne oerwinne. Op Haiku wurdt alles automatysk dien!
- ELF-bestannen dy't gjin útfierberensbit hawwe, krije ien automatysk as jo dûbelklikke yn 'e triembehearder.
- Applikaasjes kinne ynboude boarnen hawwe, lykas ikoanen, dy't wurde werjûn yn 'e triembehearder. D'r is gjin ferlet om in boskje ôfbyldings te kopiearjen yn spesjale mappen mei ikoanen, en dêrom is it net nedich om se op te romjen nei it wiskjen of ferpleatse fan de applikaasje.
- D'r is in databank foar it keppeljen fan applikaasjes mei dokuminten, d'r is gjin needsaak om bestannen hjirfoar te kopiearjen.
- Yn 'e lib/-map neist it útfierbere bestân wurde bibleteken standert trochsocht.
- D'r binne gjin tal fan distribúsjes en buroblêdomjouwings; wat ek wurket, wurket oeral.
- D'r is gjin aparte module om út te fieren dy't oars is as de map Applications.
- Applikaasjes hawwe gjin ynboude absolute paden nei har boarnen; se hawwe spesjale funksjes foar it bepalen fan de lokaasje by runtime.
- It idee fan komprimearre triemsysteemôfbyldings is yntrodusearre: dit is elk hpkg-pakket. Allegear wurde monteard troch de kernel.
- Elk bestân wurdt iepene troch de applikaasje dy't it makke hat, útsein as jo eksplisyt oars oantsjutte. Hoe cool is dit!
Twa png-bestannen. Opmerking de ferskate ikoanen dy't oanjaan dat se sille wurde iepene troch ferskate applikaasjes as se dûbelklikke. Let ek op it útklapmenu "Iepenje mei:" wêr't de brûker in yndividuele applikaasje kin selektearje. Hoe ienfâldich!
It liket derop dat in protte fan 'e krukken en oplossingen nedich binne troch AppImage op Linux net nedich wurde op Haiku, dy't de ienfâld en ferfining yn' e kearn hat dy't it makket dat it de measte fan ús behoeften behannelet.
Hat Haiku dochs app-pakketten nedich?
Dit liedt ta in grutte fraach. As it in folchoarder fan grutte makliker wie om in systeem lykas AppImage op Haiku te meitsjen dan op Linux, soe it it wurdich wêze om te dwaan? Of hat Haiku, mei syn hpkg-pakketsysteem, de needsaak om sa'n idee te ûntwikkeljen effektyf elimineare? No, om te beantwurdzjen moatte wy sjen nei de motivaasje efter it bestean fan AppImages.
Perspektyf fan brûkers
Litte wy nei ús einbrûker sjen:
- Ik wol in applikaasje ynstallearje sûnder om in administrator (root) wachtwurd te freegjen. D'r is gjin konsept fan in behearder op Haiku, de brûker hat folsleine kontrôle, om't it in persoanlik systeem is! (Yn prinsipe kinne jo dit foarstelle yn multiplayer-modus, ik hoopje dat de ûntwikkelders it ienfâldich hâlde)
- Ik wol de lêste en bêste ferzjes fan applikaasjes krije, sûnder te wachtsjen oant se yn myn distribúsje ferskine (meastentiids betsjut dit "nea", teminsten útsein as ik it heule bestjoeringssysteem bywurkje). Op Haiku is dit "oplost" mei driuwende releases. Dit betsjut dat it mooglik is om de lêste en bêste ferzjes fan applikaasjes te krijen, mar om dit te dwaan moatte jo de rest fan it systeem konstant bywurkje, it effektyf omsette yn in "bewegend doel".
- Ik wol ferskate ferzjes fan deselde applikaasje njonken inoar, om't d'r gjin manier is om te witten wat is brutsen yn 'e lêste ferzje, of, sis, ik, as webûntwikkelder, moat myn wurk testje ûnder ferskate ferzjes fan 'e browser. Haiku lost it earste probleem op, mar net it twadde. Updates wurde weromrôle, mar allinich foar it heule systeem; it is ûnmooglik (foar safier't ik wit) om bygelyks ferskate ferzjes fan WebPositive of LibreOffice tagelyk út te fieren.
Ien fan 'e ûntwikkelders skriuwt:
Yn essinsje is de rationale dit: de use case is sa seldsum dat optimalisearjen dêrfoar gjin sin hat; behannelje it as in spesjaal gefal yn HaikuPorts liket mear dan akseptabel.
- Ik moat apps hâlde wêr't ik se leuk fyn, net op myn opstartstasjon. Ik ha faaks te min skiifromte, dus ik moat in eksterne skiif of netwurkmap ferbine om applikaasjes op te slaan (alle ferzjes dy't ik haw ynladen). As ik sa'n stasjon ferbine, moat ik applikaasjes starte troch te dûbelklikken. Haiku bewarret âlde ferzjes fan pakketten, mar ik wit net hoe't ik se nei in eksterne stasjon ferpleatse, of hoe't ik letter applikaasjes fan dêrút starte.
Kommentaar fan ûntwikkelders:
Technysk is dit al mooglik mei it mount kommando. Fansels, wy sille meitsje in GUI foar dit sa gau as wy hawwe genôch ynteressearre brûkers.
- Ik haw gjin miljoenen bestannen nedich ferspraat oer it bestânsysteem dat ik sels net mei de hân kin beheare. Ik wol ien bestân per applikaasje dat ik maklik kin downloade, ferpleatse, wiskje. Op Haiku wurdt dit probleem oplost mei help fan pakketten
.hpkg, dy't bygelyks python oermeitsje fan tûzenen bestannen yn ien. Mar as der bygelyks Scribus is mei python, dan moat ik mei op syn minst twa bestannen dwaande hâlde. En ik moat der foar soargje om ferzjes fan har te hâlden dy't mei elkoar wurkje.
Meardere ferzjes fan AppImages rinne njonken inoar op deselde Linux
In perspektyf fan in applikaasjeûntwikkelder
Litte wy sjen fanút it eachpunt fan in applikaasje-ûntwikkelder:
- Ik wol de hiele brûkersûnderfining kontrolearje. Ik wol net ôfhinklik wêze fan in bestjoeringssysteem om my te fertellen wannear en hoe ik applikaasjes moat frijlitte. Haiku lit ûntwikkelders wurkje mei har eigen hpkg-repositories, mar dit betsjut dat brûkers se manuell moatte ynstelle, wat it idee "minder oantreklik" makket.
- Ik haw in download side op myn webside dêr't ik distribuearje
.exefoar Windows,.dmgfoar Mac en.AppImagefoar Linux. Of miskien wol ik de tagong ta dizze side monetarisearje, alles is mooglik? Wat moat ik dêr foar Haiku sette? De triem is genôch.hpkgmei ôfhinklikens allinich fan HaikuPorts - Myn software fereasket spesifike ferzjes fan oare software. Bygelyks, it is bekend dat Krita fereasket in patched ferzje fan Qt, of Qt dat is fyn ôfstimd op in spesifike ferzje fan Krita, op syn minst oant de patches wurde skood werom yn Qt. Jo kinne pakket dyn eigen Qt foar jo applikaasje yn in pakket
.hpkg, mar nei alle gedachten is dit net wolkom.
Reguliere applikaasje download side. Wat moat ik hjir pleatse foar Haiku?
Will bondels (besteand as applikaasje-mappen lykas AppDir of .app yn Apple-styl) en / of ôfbyldings (yn 'e foarm fan swier oanpaste AppImages of .dmg fan Apple) applikaasjes in nuttige tafoeging oan 'e Haiku-buroblêdomjouwing? Of sil it it hiele byld ferwetterje en liede ta fersnippering, en dêrtroch kompleksiteit tafoegje? Ik bin ferskuord: oan 'e iene kant is de skientme en ferfining fan Haiku basearre op it feit dat d'r meastentiids ien manier is om wat te dwaan, ynstee fan in protte. Oan 'e oare kant is de measte ynfrastruktuer foar katalogussen en / of applikaasjesuites al yn plak, sadat it systeem ropt om de oerbleaune pear prosint op syn plak te fallen.
Neffens de ûntwikkelder
Op Linux se (katalogussen en applikaasjekits, - ca. oersetter) binne nei alle gedachten in technyske oplossing foar systemyske problemen. By Haiku wy leaver gewoan systeemproblemen op te lossen.
Wat tinkt jo?
Foardat jo antwurdzje ...
Wachtsje, litte wy in rappe realiteitskontrôle dwaan: feitlik applikaasje mappen - al diel út fan Haiku:
Applikaasjemappen besteane al op Haiku, mar wurde noch net stipe yn de triembehearder
Se wurde gewoan net sa goed stipe as bygelyks de Macintosh Finder. Hoe cool soe it wêze as de QtCreator triemtafel hie in "QtCreator" namme en byldkaike yn 'e boppeste linker hoeke, launching de applikaasje doe't dûbelklik?
In bytsje earder ik al :
Binne jo wis dat jo jo desennia-âlde apps hjoed kinne útfiere as alle app-winkels en distribúsje-repositories har en har ôfhinklikens fergetten binne? Binne jo der wis fan dat jo yn 'e takomst noch tagong krije ta jo hjoeddeistige baan?
Is d'r al in antwurd fan Haiku, of kinne katalogen en applikaasjebundels hjir helpe? Ik tink dat se kinne.
Neffens dhr. waddlesplash:
Ja, wy hawwe it antwurd op 'e fraach: wy sille dizze applikaasjes gewoan stypje sa lang as nedich is oant immen har bestânsformaten op' e juste manier kin lêze of ien-op-ien funksjonaliteit leverje. Us ynset foar it stypjen fan BeOS R5-apps op Haiku is bewiis fan dit ...
Dit is wier!
Hokker aksje moat Haiku nimme?
Ik kin my it freedsume gearhing fan hpkg, mappen en applikaasjeôfbyldings foarstelle:
- Systeem software brûkt
.hpkg - Foar de meast brûkte software (benammen dyjingen dy't rôljende releases moatte planne), brûke
.hpkg(sawat 80% fan alle gefallen) - Guon ynstallearre fia
.hpkg, applikaasjes sille profitearje fan it ferpleatsen nei in applikaasje triemtafel ynfrastruktuer (bgl. QtCreator): se wurde ferspraat as.hpkg, as foarhinne.
dhr. waddlesplash skriuwt:
As alles wat jo nedich binne is om applikaasjes te besjen yn
/system/apps, ynstee wy moatte meitsje de mappen yn Deskbar mear beheare foar brûkers, sûnt/system/appsis net bedoeld om regelmjittich te iepenjen en te besjen troch brûkers (oars as MacOS). Foar sokke situaasjes hat Haiku in oar paradigma, mar dizze opsje is yn teory akseptabel.
- Haiku ûntfangt de ynfrastruktuer foar it útfieren fan applikaasjeôfbyldings, nachtlike, trochgeande en testbuildingen fan software, lykas ek foar gefallen wêryn de brûker it "yn 'e tiid befrieze" wol, foar privee en ynterne software, en oare spesjale gebrûksgefallen (sawat 20% fan alles). Dizze ôfbyldings befetsje de bestannen dy't nedich binne om de applikaasje út te fieren
.hpkg, monteare troch it systeem, en nei't de applikaasje foltôge is - unmounted. (Miskien kin in triembehearder bestannen pleatse.hpkgyn applikaasjeôfbyldings, automatysk as op fersyk fan 'e brûker - goed, lykas as jo in applikaasje slepe nei in netwurkmap of ekstern stasjon. It is mar in ferske! Of leaver, poëzy - haiku.) Oan 'e oare kant kin de brûker de ynhâld fan' e ôfbylding yn 'e foarm fan triemmen ynstallearje wolle.hpkg, wêrnei't se wurde bywurke en ferwurke op deselde wize as as se waarden ynstallearre fia HaikuDepot ... Wy moatte brainstorm).
Sitaat fan mr. waddlesplash:
It útfieren fan applikaasjes fan eksterne skiven of netwurkmappen kin mooglik nuttich wêze. En it tafoegjen fan de mooglikheid om mear "sônes" te konfigurearjen foar pkgman soe perfoarst in moaie funksje wêze.
Sa'n systeem soe profitearje fan hpkg, mappen en applikaasjeôfbyldings. Se binne goed yndividueel, mar tegearre sille se ûnoerwinlik wurde.
konklúzje
Haiku hat in ramt dat in ienfâldige en ferfine brûkersûnderfining foar PC's leveret, fier boppe wat typysk foar Linux PC's wurdt levere. Pakket systeem .hpkg is sa'n foarbyld, mar de rest fan it systeem is ek trochdrenkt mei ferfining. Haiku soe lykwols profitearje fan juste map- en applikaasjeôfbyldingsstipe. Hoe dit it bêste te dwaan is it wurdich te besprekken mei minsken dy't Haiku, har filosofy en arsjitektuer folle better kenne as ik. Ik haw ommers in bytsje mear as in wike Haiku brûkt. Dochs leau ik dat de ûntwerpers, ûntwikkelders en arsjitekten fan Haiku sille profitearje fan dit frisse perspektyf. Op syn minst soe ik bliid wêze om har "sparringpartner" te wêzen. Ik haw mear as 10 ars praktyske ûnderfining mei Linux applikaasje katalogussen en bondels, en ik soe graach fine in gebrûk foar harren yn Haiku, dêr't ik tink dat se binne in perfekte fit. De potinsjele oplossings dy't ik haw foarsteld binne lang net de iennichste korrekte foar de problemen dy't ik haw beskreaun, en as it Haiku-team beslút oare, eleganter te finen, bin ik der allegear foar. Yn prinsipe tink ik al oer it idee fan hoe't jo in systeem meitsje kinne hpkg noch verbazingwekkender sûnder de manier wêrop it wurket te feroarjen. It docht bliken dat it Haiku-team al lang neitocht hie oer applikaasjebundels by it útfieren fan in pakketbehearsysteem, mar spitigernôch ( tink ik) waard it idee "ferâldere". Miskien is it tiid om it opnij te meitsjen?
Besykje it sels! It Haiku-projekt leveret ommers ôfbyldings foar it opstarten fan DVD of USB, generearre .
Hasto noch fragen? Wy noegje jo út foar it Russysk-sprekkende .
Flateroersjoch:
fan oersetting: dit is it achtste en lêste artikel yn de rige oer Haiku.
List fan artikels:
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Hat it sin om it hpkg-systeem nei Linux te portearjen?
-
dat
-
gjin
-
Al útfierd, skriuw ik yn 'e kommentaren
20 brûkers stimden. 5 brûkers ûntholden har.
Boarne: www.habr.com