🥇Veel midagi: Haiku rakenduste paketid?

TL;DRKas Haiku saab korralikku tuge rakenduste pakettide, näiteks rakenduste kataloogide (nagu Mac'is) ja/või rakenduste piltide (Linux .app ) jaoks? Tundub, et see oleks väärt täiendust, mille rakendamine oleks lihtsam kui muudes süsteemides, arvestades, et enamus infrastruktuurist on juba olemas. AppImageNädal tagasi

avastasin Haiku, üllatavalt hea süsteemi. Kuna olen pikka aega huvitatud olnud kataloogidest ja rakenduste piltidest (inspireerituna Macintosh' lihtsusest), pole üllatav, et mulle tuli see idee pähe… Kogu arusaamiseks: olen AppImage'i looja ja autor, Linuxi rakenduste levitamise formaadi, mis on suunatud Maci lihtsusele ja pakub täielikku kontrolli rakenduste autoritele ja lõppkasutajatele (taha rohkem teada — vaata.

Mida kui me teeksime Haiku jaoks AppImage'i? wiki ja dokumentatsioon).

Räägime veidi, puhtalt teoreetiliselt, et mis oleks vajalik, et saada

, või midagi sarnast, Haikus? Ei pea kohe midagi looma, kuna Haikus olemasolev süsteem töötab üllatavalt hästi, kuid kujuteldav katse oleks hea. Ja see demonstreerib Haiku peenust, võrreldes Linuxi töökeskkondadega, kus sarnaste asjade tegemine on kohutavalt raske (mul on õigus seda öelda: olen juba 10 aastat hädas tõrgete lahendamisega). AppImageMacintosh System 1-s oli iga rakendus eraldi fail, mida hallati Finder'is. Kasutades AppImage'i, püüan taasesitada sama kasutajakogemust Linuxis.

Esiteks, mis asi on AppImage? See on süsteem kolmandate osaliste rakenduste väljaandmiseks (näiteks,

), mis võimaldab rakendusi välja anda millal ja kuidas nad soovivad: pole vaja tunda erinevate distributsioonide eripärasid, koostamisreegleid või koostamisinfra struktuuri, ei ole vaja tugiteenuseid, ja need ei ütle kasutajatele, mida (ei)tohi enda arvutisse installida. AppImage'i tuleb mõista kui midagi, mis sarnaneb Mac'i pakettide formaadiga Ultimaker Curadisk image'i sees .app . Peamine erinevus seisneb selles, et rakendusi ei kopeerita, vaid need jäävad alati AppImage'i sisse, umbes nii, nagu Haiku paketid .dmgmount'itakse, ja ei installita kunagi tavalisel mõttes. .hpkg paigaldatakse ja kunagi ei installita tavapärases mõttes.

AppImage on üle kümne aasta jooksul saanud teatud atraktiivsuse ja populaarsuse: isegi Linus Torvalds on selle avalikult heaks kiitnud, ning tuntud projektid (näiteks LibreOffice, Krita, Inkscape, Scribus, ImageMagick) on selle vastu võtnud kui peamise meetodi pidevate või öiste ehituste jagamiseks, mis ei sega kasutajate installitud ega installimata rakendusi. Siiski, töökeskkonnad ja Linuxi distributsioonid on sageli jätkuvalt kinnitatud traditsioonilise, tsentraliseeritud levitamismudeli külge, mis põhineb kaasavatel ja/või promooduvad omaette ettevõtte äriline ja/või inseneriprogrammide baasil Flatpak (RedHat, Fedora, GNOME) ja Snappy (Canonical, Ubuntu). Asjade käik on juba koomiliseks muutumas Kui kõik töötab.

Iga AppImage sisaldab kahte osa: väikest kahekordse klõpsuga käivitatavat ELF (nn

runtime.c ), millele järgneb failisüsteemi piltSquashFS SquashFS failisüsteem sisaldab rakenduse ja kõike vajalikku selle käivitamiseks, mida ei saa mõistlikus mõttes pidada igasuguse uuema sihitud süsteemi (Linuxi distributsioon) vaikeinstalleerimise osaks. Samuti sisaldab see metaandmeid, näiteks rakenduse nime, ikoone, MIME tüüpe jne..

Kasutaja poolt käivitamisel kasutab runtime FUSE ja squashfuse failisüsteemi montaaži, seejärel töötleb see teatud sisenemispunkti (nn AppRun) käivitamist montaažitud AppImage'i sees.

Failisüsteem lahutatakse pärast protsessi lõpetamist.
Tundub, et kõik on lihtne.

Aga need asjad teevad kõik keerulisemaks:

niivõrd mitmekesiste Linuxi distributsioonide tõttu ei saa enam midagi „mõistlikus mõttes” nimetada „igaks uuemaks sihtsüsteemi vaikimisi installatsiooni osaks”. Me lahendame selle probleemi, koondades

excludelist , mis võimaldab määrata, mis pakitakse AppImage'i, ja mida tuleb mujalt võtta. Sellegipoolest, vahel me eksime, kuigi põhimõtteliselt kõik töötab suurepäraselt. Seetõttu soovitame pakettide loojatel testida AppImage'e kõigis sihtrühmades (distributsioonides).Rakendused kasuliku koormana peavad olema failisüsteemis liikuvad. Kahjuks on paljudes rakendustes kindlad absoluutsed teed näiteks ressurssidele
. Seda tuleb kuidagi parandada. Lisaks tuleb kas eksportida /usr/share, või parandada LD_LIBRARY_PATHrpath rpath et selleks, et laadija saaks leida seotud teeke. Esimesel meetodil on omad puudused (mida ületatakse keeruliste lahendustega), teine on lihtsalt kohmakas.
Suurim UX lõks kasutajate jaoks on see, et tuleb seada täitmisõigus AppImage failile pärast allalaadimist. Usuge või mitte, kuid see on mõne jaoks tõeline takistus. Täitmisõiguse seadmine on kohmakas isegi kogenud kasutajate jaoks. Ringtee lahendusena pakkusime välja väikese teenuse, mis jälgib AppImage faile ja seab neile täitmisõiguse. Puhtal kujul, mitte kõige parem lahendus, kuna see ei toimi „karbi seest“ välja. Linuxi distributsioonid ei paku seda teenust, seega on kasutajate jaoks „karbi seest“ kõik halb.
Linuxi kasutajad ootavad, et uuel rakendusel oleks käivitamismenüüs ikoon. Süsteemile ei saa öelda: „Vaata, seal on uus rakendus, alusta töötamist“. Selle asemel, vastavalt XDG spetsifikatsioonile, on vajalik kopeerida fail .desktop õigesse kohta /usr üldkasutamiseks, või $HOME individuaalseks kasutamiseks. Teatud suurusega ikoonid, vastavalt XDG spetsifikatsioonile, tuleb paigutada kindlatesse kohtadesse usr või $HOME, pärast mida tuleb käivitada käsud töökeskkonnas ikoonide vahemälu uuendamiseks, või loota, et töölaud reageerib õigesti ja avastab kõik automaatselt. Sama kehtib MIME tüüpide kohta. Ringtee lahendusena soovitatakse kasutada sama teenust, mis lisaks täitmisõiguse seadmisele kopeerib olemasolevad ikoonid jne AppImage'ist soovitud kohtadesse vastavalt XDG-le. Eemaldamisel või liigutamisel eeldatakse, et teenus koristab kõik. Muidugi on igas töökeskkonnas erinevusi käitumises, graafiliste failide formaatides, nende suurustes, salvestuskohtades ja vahemälu värskendamise viisides, mis kõik tekitab probleeme. Lühidalt öeldes, see meetod on ajutine lahendus.
Kui eelnevad lahendused ei piisa, pole failihalduris ikkagi AppImage'i ikooni. Linuxi maailmas ei ole siiani otsustatud elficon'i integreerimise üle (hoolimata sellest, et arutelu ja tehnoloogia), seega ei ole ikooni rakendusse otse sisestada. Seega on rakendustel failihalduris oma ikoone (olgu need AppImage või midagi muud) ainult käivitamismenüüs. Alternatiivina kasutame miniatuure — mehhanismi, mis algselt loodi, et lauainterfeisside haldurid saaksid graafikafaile eelvaateks näidata väikeseid pilte. Seetõttu töötab ka bitifaili täitmise teenus /usr ja $HOME. Samuti puhastab see teenus ära, kui AppImage kustutatakse või liigitatakse. Kuna iga lauainterfeiss käitub veidi erinevalt, näiteks millistes formaatides see ikoone aktsepteerib, millistes suurustes või kohtades, on see tõeliselt valus.
Rakendus kukub lihtsalt täitmise ajal kokku, kui tekivad vead (näiteks kui on raamatukogu, mis ei kuulu põhitehnikasse ja ei ole AppImage'is), ning keegi ei üteldi GUI-s kasutajale, mis tegelikult toimub. Alustasime evakueerimist, kasutades teavitamine laual, ja seega peame reaalajas konsoolist vead püüda, tõlgendama need kasutajatele arusaadavateks sõnumiteks, mis tuleb seejärel kuvada lauale. Ja muidugi käsitleb igasugune töökeskkond neid veidi erinevalt.
Praeguse seisuga (septembris 2019 — tõlkija märkus) ei leidnud ma lihtsat viisi, kuidas süsteemile öelda, et faili 1.png peab avama Krita abil, ja 2.png — GIMP-iga.

Kasutamise koht, kus on olemas cross-desktop spetsifikatsioonid, mida kasutatakse GNOME, KDE ja Xfce on freedesktop.org

Kuni Haiku töökeskkonna sügavale sügavale õrnusele jõudmine on keeruline, kui mitte öelda 'võimatu', dank freedesktop.org-i XDG nähud cross-desktopi jaoks ja nendele spetsifikatsioonidele tuginevate lauainterfeisside haldurite rakendused. Näiteks võib tuua ühe üldise süsteemi ikooni Firefoxi jaoks: ilmselt ei tulnud XDG autoritele pähe, et kasutajal võib olla mitu versiooni ühest ja samast rakendusest. Ikoonid erinevate Firefoxide versioonide jaoks

Erinevate Firefoxide versioonide ikoonid

Mulle oli huvitav teada, mida Linuxi maailm võiks õppida Mac OS X-lt, et mitte eksida süsteemi integreerimisel. Kui teil on aega ja tegite sellega midagi seotud — kindlasti lugege, mida ütles Arno Gourdoll, üks esimesi Mac OS X insenere:

Soovisime, et rakenduse installimine oleks sama lihtne, kui lohistada rakenduse ikoon kuskilt (serverilt, väliselt kettalt) oma arvuti kettale. Selleks on rakenduse paketis säilitatud kogu teave, sealhulgas ikonid, versioon, töödeldav failitüüp ja URL-skeemi tüüp, mida süsteem peab rakenduse töötlemiseks teadma. Siia alla kuulub ka info „tsentraliseeritud salvestuse” kohta Icon Services ja Launch Services andmebaasis. Rakenduse jõudluse toetamiseks „tuvastatakse” rakendused mitmes „hästi tuntud” kohas: süsteemi ja kasutaja kataloogis Applications ning automaatselt teistes, kui kasutaja on Finderis liikunud katalooge, kus rakendus asub. Praktikas on see väga hästi toiminud.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sessioon 144 — Mac OS X: rakenduste pakkimine ja dokumentide printimine.

Linuxi töökeskkondades pole midagi sellist infrastruktuuri, mistõttu otsime väljapääsu projektis AppImage olevatest struktuurilistest piirangutest.

Kas Haiku tõttab appi?

Ja veel: Linuxi platvormid töökeskkondade alusena on tavaliselt nii aladokumenteeritud, et paljud asjad, mis on täieliku stackiga kooskõlastatud süsteemis väga lihtsad, tekitavad Linuxis frakmenteerituse ja keerukuse tõttu pettumust. Olen pühendanud terve ettekande Linuxi töökeskkondade platvormiga seotud küsimustele (kogenud arendajad on kinnitanud: asjad jäävad veel väga pikaks ajaks niisuguseks).

Minu ettekande pealkiri Linuxi töökeskkondade probleemidest 2018.

Isegi Linus Torvalds tunnustas, et just frakmenteerituse tõttu ei ole töökeskkondade idee õnnestunud.

Hea on näha Haikut!

Haiku puhul on kõik uskumatult lihtne

Kuigi naiivne lähenemine AppImage'i "ülekandmiseks" Haikule tähendab lihtsalt selle komponentide (peamiselt runtime.c ja teenuse) koostamist (mis võib isegi olla võimalik!), ei too see Haikule suurt kasu. Sest tegelikult on enamik neist probleemidest Haikus lahendatud ja kontseptuaalselt põhjendatud. Haiku pakub just neid ehitusplokke süsteemi infrastruktuurile, mida ma olen pikalt otsinud Linuxi töökeskkondades ja ei suutnud uskuda, et neid seal pole.

Usuge või mitte, aga seda ei suuda paljud Linuxi kasutajad üle saada. Haikus teeb kõik automaatselt!

Failid ELF, millel ei ole käivitusbitit, saavad selle automaatselt kahekordse klõpsuga failihalduris.
Rakendustel võivad olla sisseehitatud ressursid, näiteks ikoonid, mis kuvatakse failihalduris. Pole vaja kopeerida hulgaliselt pilte spetsiaalsetesse ikoonide kataloogidesse ja seega ei ole vajalik neid puhastada pärast rakenduse kustutamist või liigutamist.
On andmebaas rakenduste sidumiseks dokumentidega, pole vaja kopeerida ühtegi faili selleks.
Kataloogis lib/ otsitakse teeke vaikimisi koos täitmisfailiga.
Ei ole arvukalt jaotusi ega töölauakeskkondi; kõik, mis töötab, töötab igal pool.
Erakordset moodulit käivitamiseks, mis erineb rakenduste kataloogist, ei eksisteeri.
Rakendustes ei ole sisseehitatud absoluutseid teid oma ressurssideni; olemas on spetsiifilised funktsioonid asukoha määramiseks täitmisel.
Sisse on viidud kompaktsete failisüsteemide kujutised: iga hpkg-pakett. Kõik need monteeritakse kerneli poolt.
Iga fail avatakse selle rakenduse poolt, mis selle lõi, kui ei ole selgesõnaliselt määratud midagi muud. See on niivõrd lahe!

Kaks png-faili. Pange tähele erinevaid ikoone, mis näitavad, et neid avatakse kahekordse klõpsuga erinevate rakendustega. Samuti pidage meeles väljalaske menüüd "Ava:", kus kasutaja saab valida konkreetse rakenduse. Kui lihtne!

Tundub, et paljusid kummiköisi ja kõrvalteid, mida AppImage vajab Linuxis, pole Haikus enam vaja, mille aluseks on lihtsus ja rafineeritus, mis katab enamiku meie vajadustest.

Kas Haiku vajab lõpuks rakenduste pakette?

See on suur küsimus. Kui Haikus oleks palju lihtsam luua süsteemi, mis sarnaneb AppImage'iga, kui Linuxis, kas tasuks sellega tegeleda? Või on Haiku oma hpkg paketihaldussüsteemiga sisuliselt välistanud sellise idee arendamise? Sellele küsimusele vastamiseks tuleb vaadata AppImage'ide olemasolu motivatsiooni.

Kasutaja vaatenurk

Vaatame meie lõppkasutajat:

Soovin installida rakenduse ilma administraatori (root) parooli küsimata. Haikus ei ole administraatori mõistet, kuna kasutajal on täielik kontroll, sest see on isiklik süsteem! (Põhimõtteliselt võiks seda ette kujutada ka mitmikkasutaja režiimis, loodan, et arendajad säilitavad lihtsuse)
Soovin saada uusimaid ja parimaid rakenduste versioone, mitte oodata, kuni need minu jaotisesse ilmuvad (enamasti tähendab see 'kunagi', vähemalt kui kogu operatsioonisüsteemi ei uuendata). Haikus on see 'lahendatud' ujuvate väljaannetega. See tähendab, et on võimalik saada uusimaid ja parimaid rakenduste versioone, kuid sellega kaasneb vajadus pidevalt uuendada ka ülejäänud süsteemi, muutes selle tegelikult 'liikuvaks sihtmärkideks'..
Tahan, et mul oleks mitmeid versioone samast rakendusest kõrvuti, kuna ei saa kunagi teada, mis on viimasest versioonist riknenud, või näiteks pean kui veebiarendaja oma tööd erinevates brauseriversioonides kontrollima. Haikus on esimene probleem lahendatud, kuid teine mitte. Uuendused on tagasi pööratavad, kuid ainult kogu süsteemi jaoks, ei saa (kui ma eksin) käivitada mitut versiooni WebPositive'ist või LibreOffice'ist samaaegselt.

Üks arendajatest kirjutab:

Sisuliselt on põhjendus järgmine: kasutusstsenaarium on nii haruldane, et selle jaoks optimeerimine ei ole mõistlik; selle käsitlemine erandina HaikuPortsis tundub rohkem kui vastuvõetav.

Pean rakendusi säilitama seal, kus mulle meeldib, mitte ainult käivitusketas. Mu kettalt saab tihti ruum otsa, nii et pean ühendama välist ketast või võrgu katalooge rakenduste (kõigi versioonide, mis olen alla laadinud) säilitamiseks. Kui ma ühendaksin sellise ketta — siis peaks rakendused käivituma topeltklõpsuga. Haiku säilitab vanad pakettversioonid, kuid ma ei tea, kuidas neid välisele kettale liigutada, samuti kuidas pärast sealt rakendusi käivitada.

Arendaja kommentaar:

Tehniliselt on see juba võimalik mount meeskonna abil. Loomulikult loome me selleks GUI, nii pea kui huvilisi on piisavalt.

Mulle ei ole vaja miljoneid faile, mis on laiali jaotatud failisüsteemis, millega ma ei saa ise käsitsi tegutseda. Soovin ühe faili rakenduse kohta, mille ma saan lihtsalt alla laadida, liigutada või kustutada. Haikus on see probleem lahendatud paketiga .hpkg, mis viib näiteks pythoni tuhandetest failidest üheks. Kuid kui on näiteks Scribus, mis kasutab pythoni, tuleb mul tegeleda vähemalt kahe failiga. Ja ma pean hoolitsema, et nende töötavad versioonid oleksid omavahel kooskõlas.

Kumerad versioonid AppImages, mis käivitatakse üksteise kõrval ühes Linuxis

Vaade rakenduste arendaja seisukohalt

Vaatame rakenduste arendaja seisukohalt:

Soovin täielikult juhtida kasutajakogemust. Ei soovi sõltuda operatsioonisüsteemist, mis ütleb mulle, millal ja kuidas ma pean rakendusi välja andma. Haikus saavad arendajad töötada oma hpkg repositooriatega, kuid see tähendab, et kasutajad peavad need käsitsi seadistama, mis muudab selle idee "vähem atraktiivseks".
Mul on minu veebisaidil allalaadimise leht, kus jagan .exe Windowsile, .dmg Macile ja .AppImage Linuxile. Võib-olla soovin ma selle lehe juurdepääsu rahastada, mis iganes? Mida pean ma seal Haiku jaoks esitama? Piisab failist .hpkg ainult HaikuPortsist sõltuvustega
Minu tarkvara vajab teatud versioone teisest tarkvarast. Näiteks on teada, et Krita vajab parandatud versiooni Qt-st või Qt-d, mis on täpselt kohandatud konkreetse Krita versiooniga, vähemalt kuni parandused tagasi Qt-sse tulevad. Võib pakkida oma Qt rakenduse paketti .hpkg, kuid tõenäoliselt ei ole see soovitatav.

Tavaline rakenduse allalaadimise leht. Mida siin Haiku jaoks esitada?

Kas komplektid (mis eksisteerivad rakenduste kataloogidena, nagu AppDir või .app Apple'i stiilis) ja/või pildid (väga muudetud AppImages kujul või .dmg Kas Apple'i rakendused kasuks Haiku töökeskkonna jaoks? Või rikuvad need terviklikku pilti ning toovad kaasa killustumise, mis omakorda suurendab keerukust? Olen kahe vahel: ühelt poolt põhineb Haiku ilu ja rafineeritus sellel, et midagi saab teha tavaliselt vaid ühel viisil, mitte mitmel. Teiselt poolt on suurem osa infrastruktuurist kataloogide ja/või rakenduste komplektide jaoks juba olemas, seega kutsub süsteem üles ka viimased paar protsenti oma kohtadele.

Arendaja sõnul mr. waddlesplash

Linuxis (kataloogid ja rakenduste komplektid - tõlkija märkus) on tõenäoliselt tehniline lahendus süsteemsetele probleemidele. Haikus eelistame lihtsalt lahendada süsteemseid probleeme.

Aga mida sina arvad?

Enne kui vastate…

Oodake, teeme kiire reaalsuse kontrolli: tegelikult rakenduste kataloogid on juba osa Haikust:

Rakenduste kataloogid eksisteerivad juba Haikus, kuid neid ei toetata veel failihalduris

Need lihtsalt ei ole nii hästi toetatud kui näiteks Macintosh Finderis. Kui lahe oleks, kui QtCreatori kataloogil oleks ülemises vasakus nurgas nimi ja ikoon 'QtCreator', mis käivitaks rakenduse kahekordse klõpsuga?

Varem küsisin juba kas olete kindel, et käivitate täna oma kümne aasta vanuseid rakendusi, kui kõik rakenduste poed ja distribuutorite hoidlad unustavad need ja nende sõltuvused? Kas olete kindel, et suudate tulevikus endiselt oma praegusele tööle juurde pääseda?:

Kas Haikult on juba vastus, või saavad kataloogid ja rakenduste komplektid siin aidata? Ma arvan, et saavad.

Jah, meil on küsimusele vastus: me lihtsalt toetame neid rakendusi nii kaua, kui see vajalik on, kuni keegi suudab nende failiformaate õigesti lugeda või ühekordset funktsionaalsust tagada. Meie püüe toetada BeOS R5 rakenduste toimimist Haikus on selle vahetu tõestus...

Vastavalt mr. waddlesplashile:

See on kindlasti tõsi!

Milline tegevusplaan peaks Haiku võtma?

Ma suudan ette kujutada rahumeelset koosolekut hpkg, kataloogide ja rakenduste piltide vahel:

Süsteemne tarkvara kasutab

Kõige sagedamini kasutatava tarkvara jaoks (eriti selle jaoks, mida peab planeerima ujuvate väljalaskes) kasutatakse .hpkg
(umbes 80% kõikidest juhtudest) .hpkg Mõned, mis on paigaldatud läbi
Mõned, mis on paigaldatud läbi .hpkg, rakendused saavad kasu rakenduste kataloogide infrastruktuuri üleminekust (näiteks QtCreator): need levitatakse kujul .hpkg, nagu varem.

mr. waddlesplash kirjutab:

Kui kõik, mis vajalik, on rakenduste vaatamine, /system/apps, peaksime tegema Deskbaris kataloogid kasutajate jaoks hallatavamaks, kuna /system/apps ei ole mõeldud selleks, et kasutajad avaksid ja vaataksid seda regulaarselt (erinevalt MacOS-st). Selliste olukordade jaoks on Haikul teine paradigma, kuid see variant on teoorias vastuvõetav.

Haiku saab infrastruktuuri rakenduste piltide, öiste, pidevate ja testversioonide tarkvara käivitamiseks, samuti juhtudel, kui kasutaja tahab seda 'ajal peatada', privaatsete ja sisemiste programmide ning muude erikasutuse juhtumite jaoks (umbes 20% kõigist). Need pildid sisaldavad rakenduse käivitamiseks vajalikke faile .hpkg, mis mountitakse süsteemi vahenditega, ning pärast rakenduse lõpetamist – unmountitakse. (Võib-olla võiks failihaldur faile .hpkg rakenduse piltidesse lisada automaatselt või kasutaja nõudmisel – nagu kui tõstate rakenduse võrgu katalooge või välisele kettale. See on lihtsalt laul! Täpsemalt luule – haiku.) Teisest küljest võib kasutaja soovida pildi sisu faile kujul.hpkg, mille järel need uuendatakse ja töödeldakse just nagu oleks nad installitud HaikuDepot'i kaudu... Peame aju tormi korraldama).

Citaat mr. waddlesplashilt:

Rakenduste käivitamine väliselt ketastelt või võrgu kataloogidest võib olla potentsiaalselt kasulik. Ja võimaluse lisamine seadistada rohkem 'alasid' pkgman'ile oleks kindlasti hea funktsioon.

Sarnane süsteem kasutab hpkg, kataloogide ja rakenduste piltide eeliseid. Need on head eraldi, kuid koos on nad ületamatud.

Kokkuvõte

Haiku jaoks on infrastruktuur, mis pakub lihtsat ja rafineeritud kasutajaliidest PC-dele ning ulatub kaugele kaugemale sellest, mida tavaliselt pakutakse Linuxi PC-dele. Pakettide süsteem .hpkg — üks selline näide, kuid muud süsteemi osad on samuti täidetud rafineeritusega. Siiski, Haiku kataloogide ja rakenduste piltide õige toetamisega oleks kasu. Kuidas seda kõige paremini teha — tasub arutada inimestega, kes tunnevad Haikut, selle filosoofiat ja arhitektuuri paremini kui mina. Lõppude lõpuks olen ma Haiku kasutanud veidi rohkem kui nädal. Siiski arvan, et see värske vaatenurk on kasulik Haiku disaineritele, arendajatele ja arhitektidele. Igatahes olen ma hea meelega nende jaoks „sparringupartner“. Mul on üle 10-aastane praktiline kogemus Linuxi kataloogide ja rakenduste komplektide valdkonnas ning sooviksin leida neile rakendust Haikus, mille kontseptsioon, minu arvates, sobib ideaalselt. Minu pakutud potentsiaalsed lahendused ei ole kaugeltki ainsad õiged probleemi jaoks, mida ma olen kirjeldanud, ja kui Haiku meeskond otsustab leida teisi, elegantsemaid — olen ainult kahe käega selle poolt. Põhimõtteliselt mõtlen juba, kuidas süsteemi Kas tasuks teha Haiku rafineeritumaks, lisades reegli, et paketil ei tohiks olla sõltuvusi pakettidest, mis ei kuulu veelgi imelisemaks muuta, muutes selle toimimisviisi. Selgub, et Haiku meeskond on pikka aega mõelnud rakenduste komplektide üle paketihaldussüsteemi juurutamisel, kuid kahjuks (minu arvates) on idee „vananenud“. Võib-olla on nüüd õige aeg see uuele elule äratada?

Proovige ise! Lõppude lõpuks pakub Haiku projekt allalaetavaid pilte DVD-le või USB-le, mis on loodud iga päev.
Kas teil on küsimusi? Kutsume teid venekeelsesse telegrami kanalisse.

Vigade ülevaade: Kuidas end C ja C++-ga jalga lasta. Haiku OS retseptide kogu

Alates autor tõlke: see on kaheksas ja viimane artikkel Haiku sarjast.

Artiklite nimekiri: Esimene Teine Kolmas Neljas Viies Kuuenda Seitsmes

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.