🥇Mõned muud: Haiku rakenduste paketid?

TL;DR: kas Haiku saab korralikku toetust rakenduste pakettide jaoks, näiteks rakenduste katalooge (nagu .app Macis) ja/või rakenduse kujundeid (Linux AppImage)? Mulle tundub, et see oleks väärtuslik täiendus, mille integreerimine on lihtsam kui teistes süsteemides, kuna suurem osa infrastruktuurist on juba olemas.

Nädal tagasi avastasin Haiku, ootamatult hea süsteemi. Kuna olen juba pikka aega huvitatud kataloogidest ja rakenduse kujunditest (inspireeritud Macintosh'i lihtsusest), ei ole üllatav, et see idee mulle pähe tuli…

Kogu arusaamiseks: olen AppImage'i looja ja autor, Linuxi rakenduste jagamise formaadi, mis on suunatud Mac'i lihtsusele ja annab autoritele ning lõppkasutajatele täieliku kontrolli (kui soovite rohkem teada — näe. wiki ja dokumentatsiooni).

Mis oleks, kui me teeksime AppImage'i Haiku jaoks?

Arutame natuke, puhtalt teoreetiliselt: mida oleks vaja teha, et saada AppImage, või midagi sarnast Haikus? Ei ole kohustuslik kohe midagi luua, sest juba olemasolev süsteem Haikus töötab imelisel viisil, kuid kujuteldav eksperiment oleks päris hea. See näitab ka Haiku peenust võrreldes Linuxi töökeskkondadega, kus sarnaste asjade tegemine on kohutavalt keeruline (mul on õigus nii öelda: olen juba 10 aastat hädas silumisega).

Macintosh System 1-s oli iga rakendus eraldi fail, mida hallati Finderis. Kasutades AppImage'i, püüan luua sama kasutajakogemuse Linuxis.

Esiteks, mis see AppImage siis on? See on süsteem kolmandate osapoolte rakenduste väljastamiseks (näiteks, Ultimaker Cura), mis võimaldab rakendusi välja lasta siis, kui ja kuidas neile meeldib: ei ole vaja teada erinevate distributsioonide, ehituspoliitikate või ehitusinfrastruktuuri eripära, ei ole vaja kaasagentide tuge, ja nad ei ütle kasutajatele, mida (ei)tohib oma arvutitesse installida. AppImage'i tuleks mõista kui midagi sarnast Maci pakile formaadis .app ketta pildis .dmg. Peamine erinevus on see, et rakendused ei kopeerita, vaid jäävad alati AppImage'i sisse, üsna nagu Haiku paketid .hpkg installitakse ja kunagi ei paigaldata tavapärases mõttes.

AppImage on oma enam kui 10-aastase eksisteerimise jooksul saavutanud teatud atraktiivsuse ja populaarsuse: Linus Torvalds on selle avalikult heaks kiitnud, ning laialdaselt kasutatavad projektid (näiteks LibreOffice, Krita, Inkscape, Scribus, ImageMagick) on võtnud selle peamiseks viisiks pidevate või öiste versioonide levitamiseks, mis ei sega kasutaja installitud ega installimata rakendusi. Siiski järgivad Linuxi töökeskkonnad ja distributsioonid enamasti endiselt traditsioonilist, tsentraliseeritud levitamismudelit, tuginedes tootele ja/või edendades oma ettevõtete äri- ja/või inseneriprogramme, mis põhinevad Flatpak (RedHat, Fedora, GNOME) ja Snappy (Canonical, Ubuntu). See muutub naljakaks.

Kuidas kõik töötab

Iga AppImage sisaldab kahte osa: väikest kahekordse klõpsuga käivitatavat ELF-faili (nn. runtime.c), millele järgneb failisüsteemi pilt SquashFS.

SquashFS-failisüsteem sisaldab rakenduse koormust ja kõike vajalikku selle käivitamiseks, mida ei saa normaalselt pidada vaikimisi installatsiooni osaks iga kaasaegse sihtsüsteemi (Linuxi jaotuse) jaoks. Samuti sisaldab see metaandmeid, näiteks rakenduse nime, ikoone, MIME-tüüpe jne.

Käivitamisel kasutab runtime FUSE'i ja squashfuse'i failisüsteemi montaažiks, seejärel käivitab see teatud sisenemispunkti (nn AppRun) montaažitud AppImage'is.
Failisüsteem eemaldatakse pärast protsessi lõpetamist.

Tundub, et kõik on lihtne.

Kuid need asjad kõik keerukaks teevad:

Sellise mitmekesisuse korral Linuxi jaotustes ei saa midagi enam normaalselt nimetada «igapäevaseks installatsiooni osaks igas värskes sihtsüsteemis». Me lahendame selle probleemi, koostades excludelist, mis määrab, mis pakendatakse AppImage'i ja mida tuleb kuskilt mujalt hankida. Sellegipoolest eksime me mõnikord, kuigi üldiselt töötab kõik suurepäraselt. Seetõttu soovitame pakendajatel testida AppImages kõigis sihtsüsteemides (jaotustes).
Rakendused peavad olema failisüsteemis liigeldavad. Kahjuks on paljudes rakendustes kõvasti defineeritud absoluutsete teedega, näiteks ressurssidega /usr/share. Seda tuleb kuidagi parandada. Lisaks sellele tuleb kas eksportida LD_LIBRARY_PATH, või parandada rpath selleks, et laadija leiaks seotud raamatukogud. Esimese meetodi puudustel on omad komplikatsioonid, teisel aga on lihtsalt liiga keeruline.
Suurim UX lõks kasutajatele on see, et tuleb seada täitmise õigus AppImage failile pärast allalaadimist. Tahate uskuda, tahate mitte, aga kellegi jaoks on see tõeline takistus. Täitmise õiguse seadmine on keeruline isegi kogenud kasutajatele. Ühe võimalusena pakkusime väikese teenuse installimist, mis jälgib AppImage faile ja seadistab neile täitmise õiguse. Puhtal kujul ei ole see parim lahendus, kuna see ei tööta "kasti seest". Linuxi distributsioonid ei paku seda teenust, seega on kasutajatel "kasti seest" kõik kehvasti.
Linuxi kasutajad ootavad, et uuel rakendusel oleks käivitamismenüüs ikoon. Süsteemile ei saa öelda: „Vaata, uus rakendus, hakka tööle.” Selle asemel tuleb vastavalt XDG spetsifikatsioonile kopeerida fail .desktop õigesse kohta /usr üldise süsteemi installimiseks või $HOME individuaalse jaoks. Teatud mõõtudega ikoone, vastavalt XDG spetsifikatsioonile, tuleb paigutada kindlatesse kohtadesse usr või $HOME, pärast mida tuleb käivitada käsud töökeskkonnas, et värskendada ikoonide vahemälu, või loota, et töökeskkonna haldur suudab kõik automaatselt avastada. Sarnane olukord on MIME tüüpidega. Üheks lahenduseks on kasutada sama teenust, mis lisaks käivitamisvõimekuse märgi seadistamisele kopeerib ikoonid jne AppImage’ist õigesse kohta vastavalt XDG-le, kui need on olemas. Kõrvaldades või liigutades, teenus peaks oletatavasti kõik koristama. Loomulikult on iga töökeskkonna käitumises, graafikafailide formaatides, nende mõõtudes, salvestamiskohtades ja vahemälu värskendamise meetodites erinevusi, mis tekitab probleeme. Lühidalt, see meetod on hädalahendus.
Kui eespool toodud teave ei piisa, siis failihalduris pole ka AppImage'i ikooni. Linuxi maailmas pole veel jõutud otsusele elficon'i kasutuselevõtu osas (mugavust soones) arutelu ja rakenduste), seetõttu ei saa ikooni otse rakendusse integreerida. Nii juhtubki, et rakendustel failihalduris oma ikoone ei ole (olgu need AppImage'id või miski muu), need on olemas ainult käivitamismenüüs. Alternatiivina kasutame me miniatuure – mehhanismi, mis loodi algselt selleks, et töölaua haldurid saaksid kuva vähendatud pilte graafiliste failide eelvaate ikoonidena. Seega, teenus käivitatavuse seadistamiseks toimib samuti kui "miniatuurija", luues ja salvestades ikoonide miniatuure vastavatesse kohtadesse /usr ja $HOME. Samuti teostab see teenus puhastamise, kui AppImage kustutatakse või liigutatakse. Iga töölaua haldur käitub veidi erinevalt, näiteks millistes formati ikoonid aktsepteeritakse, millistes suurustes või millistes kohtades, ja see on tõeliselt valus.
Rakendus kukub lihtsalt käivitamisel kokku, kui ilmnevad vead (näiteks on olemas teek, mis ei kuulu põhitehnoloogia alla ja mis ei ole AppImage'is saadaval), ning keegi ei teavita kasutajat GUI-s, mis tegelikult toimub. Oleme hakanud selle probleemi vältimiseks kasutama teateid töölaual, seega peame tõrkevead käsitsi käsitsema, muutma need kasutajale arusaadavateks teadeteks, mida tuleb seejärel töölaual kuvada. Ja loomulikult käsitleb iga töökeskkond neid veidi erinevalt.
Praeguse seisuga (septembris 2019 — tõlkija märkus) ei ole ma leidnud lihtsat viisi öelda süsteemile, et fail 1.png tuleb avada Krita abil, samas kui 2.png peab olema avatud GIMP-is.

Cross-desktop spetsifikatsioonide salvestuskoht, mida kasutatakse GNOME, KDE ja Xfce on freedesktop.org

Haiku töökeskkonda sügavalt põimitud rafineerituse taseme saavutamine on keeruline, kui mitte öelda 'võimatu', freedesktop.org XDG spetsifikatsioonide tõttu. cross-desktopi ja nende spetsifikatsioonide põhjal loodud töölauahalduse rakenduste jaoks. Näitena võib tuua ühe üldise ikooni Firefox: tundub, et XDG autoritele ei tulnud isegi pähe, et kasutajal võivad olla paigaldatud mitu versiooni samast rakendusest.

Erinevate versioonide Firefoxi ikoonid

Mind huvitas, mida Linuxi maailm võiks õppida Mac OS X-lt, et süsteemi integreerimisel mitte komistada. Kui teil on aega ja tegelete sellega — lugege kindlasti, mida ütles Arno Gurdol, üks Mac OS X-i esimesi insenere:

Meie soov oli, et rakenduse installimine oleks sama lihtne kui rakenduse ikooni lohistamine kuskilt (serverist, välistelt kettalt) oma arvuti kõvakettale. Selleks on rakenduse pakis salvestatud kogu teave, sealhulgas ikoonid, versioon, töödeldav faili tüüp, URL-i skeemi tüüp, mida süsteem peab teadma rakenduse töötlemiseks. Siia kuulub ka teave 'tsentraliseeritud salvestamise' kohta Icon Services'i ja Launch Services'i andmebaasis. Rakenduse jõudluse toetamiseks 'leidub' neid mitmes 'hästi tuntud' kohas: süsteemi ja kasutaja rakenduste kataloogis, samuti mõnes teises automaatselt, kui kasutaja liigub Finderis katalooge, mis sisaldavad rakendust. Praktikas on see väga hästi töödanud.

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

Selle infrastruuri sarnast ei leidu Linuxi töökeskkondades, seetõttu otsime mööda struktuursete piirangute ringi projekti AppImage.

Kas Haiku tõesti kiirustab appi?

Ja veel: Linuxi platvormid töökeskkondade aluseks on sageli nii aluseks, et paljusid asju, mis on täieliku virna korral kooskõlastatud süsteemis üsna lihtsad, häirib Linuxis killustatus ja keerukus. Olen pühendanud terve ettekande Linuxi töökeskkondadega seotud küsimustele (teadlikud arendajad on kinnitanud: nii jääb see veel väga pikaks ajaks).

Minu ettekanne Linuxi töökeskkondade probleemidest 2018. aastal.

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

Hea on näha Haiku't!

Haiku's muutub kõik uskumatult lihtsaks.

Kuigi naiivne lähenemine AppImage'i 'ülekandmisele' Haiku's seisneb lihtsas katsetamises (peamiselt runtime.c ja teenuse) selle komponentide koostamisel (mis võib isegi olla võimalik!), ei too see Haiku'le erilist kasu. Sest enamik neist probleemidest on Haiku's tegelikult lahendatud ja kontseptuaalselt põhjendatud. Haiku pakub just neid telliseid süsteemi infrastruktuuri jaoks, mida olen Linuxi töökeskkondades nii kaua otsinud ja ei suutnud uskuda, et neid seal pole. Nimelt:

Kas te uskute või mitte, kuid paljusid Linuxi kasutajaid see ei suutnud takistada. Haikus toimub kõik automaatselt!

ELF-failid, millel puudub täitmisõigus, saavad selle automaatselt kahekordse klõpsuga failihalduris.
Rakendustel võivad olla sisseehitatud ressursid, näiteks ikoonid, mis kuvatakse failihalduris. Ei ole vaja kopeerida hulgaliselt pilte spetsiaalsetesse ikoonikaustadesse, seega pole pärast rakenduse kustutamist või liigutamist nende koristamine vajalik.
On olemas andmebaas rakenduste sidumiseks dokumentidega, seega ei ole vaja kopeerida mingeid faile.
Vaikimisi otsitakse teeki lib/ kaustast koos teegi täidetava failiga.
Ei ole palju distributsioone ja töölauakeskkondi, kõik, mis töötab, töötab kõikjal.
Erinevat käivitusmoodulit, mis erineb kaustast Applications, ei eksisteeri.
Rakendustes ei ole sisseehitatud absoluutseid teid oma ressurssideni, on spetsiaalsed funktsioonid asukoha määramiseks töö ajal.
On integreeritud idee kokku surutud failisüsteemipiltidest: see on iga hpkg pakett. Kõik need monteeritakse tuumaga.
Iga fail avatakse rakenduses, mis selle lõi, kui ei ole selgesõnaliselt märgitud midagi muud. Kuidas äge see on!

Kaks png-faili. Pange tähele erinevaid ikoone, mis näitavad, et neid avatakse kahekordse klõpsuga erinevates rakendustes. Samuti pane tähele rippmenüüd "Avada rakendusega:", kus kasutaja võib valida konkreetse rakenduse. Nii lihtne!

Tundub, et paljud AppImage'i Linuxis vajalikud kikkid ja ümbersõidud ei ole Haikus vajalikud, mis oma lihtsuse ja rafineerituse tõttu suutis rahuldada enamik meie vajadustest.

Kas Haiku vajab rakenduste pakette?

See viib suure küsimuseni. Kui Haikus oleks süsteemi loomine nagu AppImage oluliselt lihtsam kui Linuxis, kas oleks seda väärt? Või on Haiku oma hpkg-pakettide süsteemiga suhestumisest juba vajaduse analooge arendada kaotanud? Noh, vastuse saamiseks peame vaatama, mis motiveerib AppImage'e olemasolu.

Kasutaja vaatenurk

Vaatame meie lõppkasutajat:

Ma tahan rakendust installida ilma administraatori (root) parooli küsimata. Haikus puudub administreerija mõisted, kasutajal on täielik kontroll, kuna see on isiklik süsteem! (Teoreetiliselt on võimalik, et see toimib ka mitme kasutaja režiimis, lootus, et arendajad säilitavad lihtsuse)
Soovin saada uusimaid ja parimaid versioone rakendustest, mitte oodata, kuni need minu jaotisesse ilmuvad (tavaliselt tähendab see "kunagi", vähemalt kui mitte uuendada kogu operatsioonisüsteemi). Haikus on see "lahendatud" ujuvate väljaannete abil. See tähendab, et on võimalus saada uusimaid ja parimaid rakenduste versioone, kuid selleks on vaja kogu süsteemi pidevalt uuendada, muutes selle tõeliseks "liikuvaks sihtmärgiks"..
Soovin, et saaksin hoida mitu versiooni samast rakendusest kõrvuti, kuna ei saa teada, mis viimasel versioonil rikutud on, või näiteks pean veebiarendajana oma tööd kontrollima erinevates brauseri versioonides. Haikus on esimene probleem lahendatud, kuid teine mitte. Uuendused on tagasivõetavad, kuid ainult kogu süsteemi kohta, ei ole võimalik (kui ma õigesti tean) käivitada näiteks mitut versiooni WebPositive või LibreOffice'i korraga.

Üks arendajatest kirjutab:

Põhimõtteliselt on põhjendus selline: kasutusstsenaarium on nii haruldane, et selle optimeerimine pole mõistlik; selle töötlemine erijuhtumina HaikuPortsis näib olevat täiesti vastuvõetav.

Ma tahan rakendusi hoida seal, kus mulle meeldib, mitte käivitusketas. Mu kettad on tihti täis, nii et pean ühendama välise kettaga või võrgu katalooge rakenduste (kõikide versioonide, mida olen alla laadinud) salvestamiseks. Kui ma sellise ketta ühendan, peab rakendusi võimalik olema käivitada kahekordse klõpsuga. Haiku säilitab vanad versioonid pakettidest, kuid ma ei tea, kuidas neid väliskettale liigutada ja kuidas neid sealt hiljem käivitada.

Arendaja kommentaar:

Tehniliselt on see juba võimalik mount käsklusega. Loomulikult teeme selle jaoks GUI, kui piisavalt huvilisi kasutajaid koguneb.

Mul ei ole vaja miljoneid faile, mis on laiali ajutud failisüsteemis ja millega ma ei saa iseseisvalt käsitsi toime tulla. Soovin, et iga rakenduse jaoks oleks üks fail, mille ma saan kergesti alla laadida, viia või kustutada. Haikus on see probleem lahendatud pakettide abil. .hpkg, mis näiteks pythonit tuhandest failist ühte viivad. Aga kui on näiteks Scribus, mis kasutab pythonit, siis pean ma tegelema vähemalt kahe failiga. Ja ma pean hoolitsema selle eest, et säilitada nende omavahel töötavad versioonid.

Rohked AppImage versioonid, mis on üksteise kõrval ühes Linuxis käimas.

Arendaja vaatenurgast.

Vaadakem arendaja seisukohast:

Ma tahan hallata kasutajakogemust täielikult. Ei taha sõltuda operatsioonisüsteemist, mis ütleks mulle, millal ja kuidas ma pean rakendusi välja laskma. Haikus saavad arendajad töötada oma hpkg hoidlatega, kuid see tähendab, et kasutajad peavad need käsitsi seadistama, mis muudab selle idee "vähem atraktiivseks".
Mul on oma veebisaidil allalaadimisleht, kus ma jagan .exe Windowsile, .dmg Macile ja .AppImage Linuxile. Ja võib-olla tahan ma selle lehe juurdepääsu teenida, kõik on võimalik? Mida peaksin sinna Haiku jaoks lisama? 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 häälestatud konkreetse Krita versiooni jaoks, vähemalt kuni parandused ei naase Qt-sse. Saab pakkida oma Qt rakenduste pakendisse .hpkg, aga tõenäoliselt ei ole see teretulnud.

Tavaline rakenduse allalaadimise leht. Mida siia paigutada Haiku jaoks?

Kas komplektid (mida esitatakse rakenduste kataloogidena, nagu AppDir või .app Apple'i stiilis) ja/või pildid (tugevalt muudetud AppImages või .dmg Apple'i rakendustest) on kasulik lisa Haiku töökeskkonnale? Või segab see terviklikku pilti ja viib fragmenteerumiseni, seega lisab keerukust? Ma olen kahe vahel: ühelt poolt põhineb Haiku ilu ja peenuse see, et tavaliselt on üks viis, kuidas midagi teha, mitte palju. Teiselt poolt on suur osa infrastruktuurist kataloogide ja/või rakenduste komplektide jaoks juba kohal, seega süsteem kutsub järele jäävaid paar protsenti oma kohtadele.

Vastavalt arendajale mr. waddlesplash

Linuxis nad (kataloogid ja rakenduste komplektid, — tõlkija märk.) on tõenäoliselt tehniline lahendus süsteemsetele probleemidele. Haikus eelistame me lihtsalt süsteemsete probleemide lahendamist.

Mida teie arvate?

Enne kui vastate…

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

Rakenduste kataloogid on Haikus juba olemas, kuid praegu ei toetata neid failihalduris.

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

Natuke varem küsisin juba küsisin.:

Kas olete kindel, et käivitad täna oma kümne aasta taguseid rakendusi, kui kõik rakenduste poed ja distributsioonide repod unustavad need ja nende sõltuvused? Kas olete kindel, et saate ikka tulevikus 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.

Kohas mr. waddlesplash:

Jah, meil on vastus küsimusele: me toetame neid rakendusi niikaua, kui vajalik, kuni keegi suudab nende failiformaate õigesti lugeda või pakkuda üks-ühele funktsionaalsust. Meie pühendumus BeOS R5 rakenduste töö jätkamisele Haiku süsteemis on selle otsene tõestus...

See on tõsi!

Millised tegevused peaks Haiku ette võtma?

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

Süsteemne tarkvara kasutab .hpkg
Kasutatakse kõige sagedamini kasutatavaid rakendusi (eriti neid, mille jaoks tuleb planeerida ujuvaid versioone) .hpkg (umbes 80% kõikidest juhtudest)
Mõned, mis on paigaldatud läbi .hpkg, rakendused saavad kasu rakenduste kataloogide infrastruktuuri üleminekust (näiteks QtCreator): neid jagatakse .hpkg, nagu varem.

hr. waddlesplash kirjutab:

Kui kõik, mis vajalik, on rakenduste vaatamine /system/apps, tuleks Deskbaris kataloogid kasutada kasutajate jaoks paremini hallatavaks, kuna /system/apps ei ole mõeldud selleks, et kasutajad seda regulaarselt avaksid ja vaataksid (erinevalt MacOS-ist). Selliste olukordade jaoks on Haikul teine paradigma, kuid see variant on põhimõtteliselt vastuvõetav.

Haiku saab infrastruktuuri rakendusepiltide, öiste, pidevate ja testikogude käivitamiseks, samuti juhtudeks, kui kasutaja soovib seda „ajal külmutada“, sise- ja isiklikuks tarkvaraks ning muude erakasutuse juhtudeks (umbes 20% kõikidest). Need pildid sisaldavad rakenduse käivitamiseks vajalikke faile .hpkg, mis mountitakse süsteemi vahenditega ja pärast rakenduse lõpetamist – unmountitakse. (Võib-olla võiks failihaldur faile panna .hpkg rakendusepiltidesse, automaatselt või kasutaja nõudmisel – nagu siis, kui lohistad rakenduse võrgukatsekatalooge või välisele kettale. See on lihtsalt laul! Täpsemalt öeldes luule – haiku.) Teiselt poolt võib kasutaja soovida installida pildi sisu failidena,.hpkg, mille järel neid uuendatakse ja töödeldakse täpselt nagu oleks need installitud läbi HaikuDepot... Peame ajurünnaku korraldama).

Tsitaat hr. waddlesplash:

Rakenduste käivitamine välistelt kõvaketastelt või võrgukaustadelt võib olla potentsiaalselt kasulik. Ja võimaluse lisamine seadistada rohkem „alasid“ pkgmanile oleks kindlasti hea funktsioon.

Sarnane süsteem kasutab hpkg, kaustade ja rakendusversioonide eeliseid. Need on head eraldi, kuid koos on nad võitmatud.

Kokkuvõte

Haiku jaoks on infrastruktuur, mis pakub arvutitele lihtsat ja rafineeritud kasutajaliidest, mis ületab oluliselt seda, mida tavaliselt Linuxi arvutitele pakutakse. Paketisüsteem .hpkg — üks selline näide, kuid ka teised süsteemi osad on rafineerituse poolest kõrgel tasemel. Siiski looks õige katalogite ja rakenduspiltide tugi Haiku jaoks kasu. Kuidas seda kõige paremini teha, tasub arutada inimestega, kes tunnevad Haiku, selle filosoofiat ja arhitektuuri oluliselt paremini kui mina. Lõppude lõpuks olen Haikut kasutanud vaid veidi üle nädala. Sellegipoolest arvan, et see värske vaatenurk on kasulik Haiku disaineritele, arendajatele ja arhitektidele. Vähemalt olen ma rõõmuga nende „sparringupartner”. Mul on üle 10 aasta praktilist kogemust Linuxi kataloogide ja rakenduste komplektidega ning mul oleks hea meel leida neile rakendust Haikus, mille kontseptsioon sobib minu arvates neile ideaalselt. Minu poolt pakutud potentsiaalsed lahendused ei ole kindlasti ainsad õiged probleemidele, mida ma kirjeldasin, ja kui Haiku meeskond otsustab leida teisi, elegantsemaid lahendusi — olen selle poolt. põhimõtteliselt mõtlen juba välja ideed, kuidas süsteemi hpkg veel põnevam, muutmata selle toimimist. Selgub, et Haiku meeskond mõtles juba pikka aega rakenduste komplektidele pakihalduse süsteemi rakendamisel, kuid kahjuks, (minu arust) läks idee "ajalukku". Võib-olla on aeg see elu tuua?

Katsuge ise! Haiku projekt pakub allalaadimiseks pilte DVD või USB, mis on loodud igal päeval..
Kas on küsimusi? Olete oodatud venekeelsesse telegrami kanalisse..

Vea ülevaade: Kuidas endale jalga tulistada C ja C++-ga. Haiku OS retseptide kogumik.

Alates autori tõlge: see on kaheksas ja viimane artikkel Haiku tsüklist.

Artiklite nimekiri: Esimene Teine Kolmas Neljas Viies Kuues Seitsmes

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