Midagi muud: Haiku rakenduste komplektid?

TL; DR: Kas Haiku saab korralikult tuge rakenduspakettidele, näiteks rakenduste kataloogidele (nt .app Macis) ja/või rakenduse kujutised (Linux AppImage)? Ma arvan, et see oleks väärt täiendus, mida on lihtsam õigesti rakendada kui teisi süsteeme, kuna suurem osa infrastruktuurist on juba paigas.

Nädal tagasi Avastasin Haiku, ootamatult hea süsteemi. Noh, kuna mind on pikka aega huvitanud kataloogid ja rakenduspildid (inspireeritud Macintoshi lihtsusest), siis pole üllatav, et mulle tuli pähe idee...

Täieliku mõistmise huvides olen ma Linuxi rakenduste levitamisvormingu AppImage looja ja autor, mille eesmärk on Maci lihtsus ja mis annab täieliku kontrolli rakenduste autoritele ja lõppkasutajatele (kui soovite rohkem teada saada, vt wiki и dokumentatsioon).

Mis siis, kui teeme haiku jaoks AppImage'i?

Mõelgem natuke, puhteoreetiliselt: mida on vaja teha, et saada AppImage, või midagi sarnast, Haiku peal? Praegu pole vaja midagi luua, sest juba Haikus olemasolev süsteem toimib hämmastavalt, aga mõtteline eksperiment oleks tore. See näitab ka Haiku keerukust, võrreldes Linuxi töölauakeskkondadega, kus sellised asjad on kohutavalt keerulised (mul on õigus seda öelda: ma olen silumisega hädas olnud 10 aastat).

Operatsioonisüsteemis Macintosh System 1 oli iga rakendus Finderis "hallatud" eraldi fail. Rakenduse AppImage abil üritan Linuxis sama kasutajakogemust uuesti luua.

Esiteks, mis on AppImage? See on süsteem kolmandate osapoolte rakenduste (näiteks Ultimaker ravi), mis võimaldab rakendusi välja anda millal ja kuidas nad soovivad: pole vaja teada erinevate distributsioonide spetsiifikat, luua poliitikaid ega ehitada infrastruktuuri, pole vaja hooldajate tuge ja nad ei ütle kasutajatele, mida (mitte) tohib installida. nende arvutites. AppImage'i tuleks mõista kui midagi sarnast Maci paketi vormingus .app ketta kujutise sees .dmg. Peamine erinevus seisneb selles, et rakendusi ei kopeerita, vaid need jäävad igaveseks AppImage'i sisse, samamoodi nagu Haiku paketid .hpkg paigaldatud ja mitte kunagi tavalises tähenduses paigaldatud.

Enam kui 10-aastase eksisteerimise jooksul on AppImage saavutanud mõningase atraktiivsuse ja populaarsuse: Linus Torvalds ise toetas seda avalikult ja ühised projektid (näiteks LibreOffice, Krita, Inkscape, Scribus, ImageMagick) on selle peamise viisina kasutusele võtnud. pidevate või igaõhtuste ehituste levitamiseks, mitte segades installitud või desinstallitud kasutajarakendusi. Kuid Linuxi töölauakeskkonnad ja distributsioonid hoiavad enamasti endiselt kinni traditsioonilisest, tsentraliseeritud hooldajapõhisest levitamismudelist ja/või reklaamivad oma ettevõtte äri- ja/või inseneriprogramme. Flatpak (RedHat, Fedora, GNOME) ja Vihane (Canonical, Ubuntu). See tuleb naeruväärselt.

Kuidas see kõik töötab

• Iga AppImage sisaldab 2 osa: väikest topeltklõpsuga ELF-i (nn. runtime.c), millele järgneb failisüsteemi kujutis SquashFS.

• SquashFS-failisüsteem sisaldab rakenduse kasulikku koormust ja kõike selle käivitamiseks vajalikku, mida ei saa mõistuse juures pidada iga üsna hiljutise sihtsüsteemi (Linuxi distributsiooni) vaikeinstalli osaks. See sisaldab ka metaandmeid, nagu rakenduse nimi, ikoonid, MIME tüübid jne jne.

• Kui kasutaja seda käivitab, kasutab Runtime failisüsteemi ühendamiseks FUSE-d ja squashfuse-i ning seejärel käitab mõne sisendpunkti (teise nimega AppRun) ühendatud AppImage'i sees.
  Failisüsteem eemaldatakse pärast protsessi lõppu.

Kõik tundub lihtne.

Ja need asjad teevad kõik keeruliseks:

• Sellise Linuxi distributsioonide mitmekesisuse korral ei saa midagi "õige mõistusega" nimetada "iga uue sihtsüsteemi vaikeinstalli osaks". Me töötame selle probleemi ümber ehitades välistatud loend, mis võimaldab teil määrata, mis pakitakse rakendusse AppImage ja mis tuleb kuhugi mujale kaasa võtta. Samas tunneme vahel puudust, hoolimata sellest, et üldiselt toimib kõik suurepäraselt. Sel põhjusel soovitame pakettide loojatel testida AppImages'i kõigis sihtsüsteemides (distributsioonides).
• Rakenduste kasulikud koormused peavad olema failisüsteemis ümber paigutatavad. Kahjuks on paljudel rakendustel sisse kodeeritud absoluutsed teed näiteks ressursside juurde /usr/share. Seda tuleb kuidagi parandada. Lisaks peate kas eksportima LD_LIBRARY_PATHvõi parandada rpath et laadija saaks leida seotud teeke. Esimesel meetodil on oma puudused (millest saab keeruliselt üle) ja teine ​​on lihtsalt tülikas.
• Kasutajate suurim UX lõks on see määrake käivitatav bitt AppImage fail pärast allalaadimist. Uskuge või mitte, kuid see on mõne jaoks tõeline takistus. Täitmisbiti seadistamise vajadus on tülikas isegi kogenud kasutajatele. Lahendusena soovitasime installida väikese teenuse, mis jälgib AppImage'i faile ja määrab nende käivitatavusbiti. Puhtal kujul pole see parim lahendus, kuna see ei tööta karbist välja võttes. Linuxi distributsioonid seda teenust ei paku, seetõttu on kasutajatel karbist väljas halb kogemus.
• Linuxi kasutajad ootavad, et uuel rakendusel oleks käivitusmenüüs ikoon. Te ei saa süsteemile öelda: "Vaata, siin on uus rakendus, teeme tööd." Selle asemel peate vastavalt XDG spetsifikatsioonile faili kopeerima .desktop õigesse kohta sisse /usr süsteemiülese installi jaoks või sisse $HOME üksikisiku jaoks. Teatud suurusega ikoonid tuleb vastavalt XDG spetsifikatsioonile paigutada teatud kohtadesse usr või $HOME, ja seejärel käivitage töökeskkonnas käsklused ikooni vahemälu värskendamiseks või lootke, et töökeskkonna haldur saab selle välja ja tuvastab kõik automaatselt. Sama MIME tüüpidega. Lahendusena tehakse ettepanek kasutada sama teenust, mis lisaks täitmislipu seadmisele teeb ikoonide olemasolul jne. kopeerige need rakenduses AppImage rakendusest AppImage XDG järgi õigetesse kohtadesse. Kustutamisel või teisaldamisel kustutab teenus eeldatavasti kõik. Muidugi on erinevusi iga töökeskkonna käitumises, graafiliste failivormingutes, nende suurustes, salvestuskohtades ja vahemälude uuendamise meetodites, mis tekitab probleemi. Lühidalt öeldes on see meetod kark.
• Kui ülaltoodust ei piisa, pole failihalduris ikka veel AppImage ikooni. Linuxi maailm pole veel otsustanud elficoni juurutada (hoolimata arutelu и rakendamine), seega ei saa ikooni otse rakendusse manustada. Seega tuleb välja, et failihalduris olevatel rakendustel polegi oma ikoone (pole vahet, AppImage või midagi muud), need on ainult startmenüüs. Lahendusena kasutame pisipilte – mehhanismi, mis oli algselt loodud selleks, et töölauahaldurid saaksid ikoonidena kuvada graafiliste failide eelvaate pisipilte. Järelikult töötab käivitatavuse biti seadistamise teenus ka "miniaturiseerijana", luues ja kirjutades ikooni pisipilte sobivatesse asukohtadesse /usr и $HOME. See teenus puhastab ka siis, kui AppImage kustutatakse või teisaldatakse. Tulenevalt asjaolust, et iga töölauahaldur käitub veidi erinevalt, näiteks millises vormingus ta ikoone vastu võtab, mis suuruses või kohtades, on see kõik tõesti valus.
• Rakendus jookseb käivitamisel lihtsalt kokku, kui ilmnevad vead (näiteks on teek, mis ei ole põhisüsteemi osa ja mida AppImage ei paku), ja keegi ei ütle kasutajale GUI-s, mis täpselt toimub. Hakkasime sellest mööda saama, kasutades selleks teatised töölaual, mis tähendab, et peame vead käsurealt kinni püüdma, teisendama need kasutajale arusaadavateks sõnumiteks, mis tuleb seejärel töölaual kuvada. Ja loomulikult käsitleb iga töölauakeskkond neid veidi erinevalt.
• Hetkel (september 2019 – tõlkija märkus) ei ole ma leidnud lihtsat viisi, kuidas süsteemile öelda, et fail 1.png tuleb avada kasutades Krita ja 2.png - GIMP-i kasutamine.

aastal kasutatud töölauaüleste spetsifikatsioonide salvestuskoht GNOME, KDE и Xfce on freedesktop.org

Haiku töökeskkonda sügavalt põimitud keerukuse taseme saavutamine on spetsifikatsioonide tõttu keeruline, kui mitte võimatu XDG saidilt freedesktop.org töölauaüleste arvutite jaoks, aga ka nendel spetsifikatsioonidel põhinevate töölauahaldurite rakenduste jaoks. Näitena võib tuua ühe kogu süsteemi hõlmava Firefoxi ikooni: ilmselt ei mõelnud XDG autorid isegi sellele, et kasutajal võib olla installitud mitu sama rakenduse versiooni.

Firefoxi erinevate versioonide ikoonid

Mõtlesin, mida võiks Linuxi maailm Mac OS X-ilt õppida, et vältida süsteemiintegratsiooni rikkumist. Kui teil on aega ja olete sellega tegelenud, lugege kindlasti, mida ütles Arnaud Gurdol, üks esimesi Mac OS X insenere:

Tahtsime teha rakenduse installimise sama lihtsaks, kui lohistada rakenduse ikooni kuskilt (serverist, välisest draivist) arvuti kettale. Selleks salvestab rakenduspakett kogu teabe, sealhulgas ikoonid, versiooni, töödeldava failitüübi, URL-i skeemide tüübi, mida süsteem peab rakenduse töötlemiseks teadma. See hõlmab ka teavet kesksalvestuse kohta Icon Services ja Launch Services andmebaasis. Jõudluse toetamiseks "avastatakse" rakendused mitmes "tuntud" kohas: süsteemi ja kasutaja rakenduste kataloogides ning mõnes teises automaatselt, kui kasutaja navigeerib rakendust sisaldavas kataloogis Finderisse. Praktikas töötas see väga hästi.

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

Linuxi lauaarvutites pole selle infrastruktuuri sarnast, seega otsime lahendusi AppImage projekti struktuuripiirangute üle.

Kas Haiku tuleb appi?

Ja veel üks asi: Linuxi platvormid töölauakeskkondade alusena kipuvad olema nii alamääratletud, et paljud asjad, mis järjepidevas täispinu süsteemis on üsna lihtsad, on Linuxis masendavalt killustatud ja keerulised. Pühendasin terve aruande töölauakeskkondade Linuxi platvormiga seotud probleemidele (teadlikud arendajad kinnitasid, et kõik jääb selliseks väga pikaks ajaks).

Minu aruanne Linuxi töölauakeskkondade probleemidest 2018. aastal

Isegi Linus Torvalds tunnistas, et killustatus oli põhjus, miks tööruumi idee ebaõnnestus.

Tore näha Haikuid!

Haiku teeb kõik hämmastavalt lihtsaks

Kui naiivne lähenemine AppImage'i Haikule "portimisel" seisneb selles, et proovite selle komponente lihtsalt üles ehitada (peamiselt runtime.c ja service) (mis võib isegi olla võimalik!), ei too see Haiku jaoks erilist kasu. Sest tegelikult on enamik neist probleemidest lahendatud haiku keeles ja on kontseptuaalselt põhjendatud. Haiku pakub täpselt neid süsteemi infrastruktuuri ehitusplokke, mida olen Linuxi töölauakeskkondadest nii kaua otsinud ja poleks uskunud, et neid seal pole. Nimelt:

Uskuge või mitte, sellest ei saa paljud Linuxi kasutajad üle. Haiku peal tehakse kõik automaatselt!

• ELF-failid, millel pole käivitatavuse bitti, saavad failihalduris topeltklõpsu korral selle automaatselt.
• Rakendustel võivad olla sisseehitatud ressursid, näiteks ikoonid, mis kuvatakse failihalduris. Pole vaja kopeerida hulga pilte spetsiaalsetesse ikoonidega kataloogidesse ja seetõttu pole vaja neid pärast rakenduse kustutamist või teisaldamist puhastada.
• Rakenduste dokumentidega sidumiseks on andmebaas, selleks pole vaja faile kopeerida.
• Käivitatava faili kõrval asuvas kataloogis lib/ otsitakse vaikimisi teeke.
• Puuduvad arvukad distributsioonid ja töölauakeskkonnad; kõik, mis töötab, töötab kõikjal.
• Pole vaja käitada eraldi moodulit, mis erineks rakenduste kataloogist.
• Rakendustel pole oma ressurssidele sisseehitatud absoluutseid teid; neil on erifunktsioonid asukoha määramiseks käitusajal.
• Tutvustatakse tihendatud failisüsteemi piltide ideed: see on mis tahes hpkg pakett. Kõik need on monteeritud kerneli poolt.
• Iga faili avab selle loonud rakendus, kui te pole selgesõnaliselt teisiti määranud. Kui lahe see on!

Kaks png-faili. Pange tähele erinevaid ikoone, mis näitavad, et topeltklõpsamisel avavad need erinevad rakendused. Pange tähele ka rippmenüüd "Ava koos:", kus kasutaja saab valida konkreetse rakenduse. Kui lihtne!

Paistab, et paljud Linuxi AppImage'i nõutavad kargud ja lahendused muutuvad Haiku puhul ebavajalikuks, kuna selle keskmes on lihtsus ja keerukus, mis muudab selle enamiku meie vajaduste rahuldamiseks.

Kas Haiku vajab siiski rakenduste pakette?

See toob kaasa suure küsimuse. Kui sellise süsteemi nagu AppImage loomine Haiku peal oleks suurusjärgu võrra lihtsam kui Linuxis, kas siis tasuks seda teha? Või on Haiku oma hpkg paketisüsteemiga tõhusalt kõrvaldanud vajaduse sellise idee arendamiseks? Noh, vastamiseks peame vaatama AppImages'i olemasolu motivatsiooni.

Kasutaja vaatenurk

Vaatame oma lõppkasutajat:

• Soovin installida rakenduse ilma administraatori (root) parooli küsimata. Haikul puudub administraatori kontseptsioon, kasutajal on täielik kontroll, kuna tegemist on isikliku süsteemiga! (Põhimõtteliselt võite seda ette kujutada mitme mängijaga režiimis, loodan, et arendajad hoiavad seda lihtsana)
• Soovin hankida rakenduste uusimaid ja parimaid versioone, ootamata, kuni need minu levitusse ilmuvad (enamasti tähendab see "mitte kunagi", vähemalt siis, kui ma ei värskenda kogu operatsioonisüsteemi). Haiku puhul on see "lahendatud" ujuvate väljaannetega. See tähendab, et on võimalik hankida rakenduste uusimad ja parimad versioonid, kuid selleks peate kogu ülejäänud süsteemi pidevalt värskendama, muutes selle tõhusalt "liikuvaks sihtmärgiks"..
• Soovin samast rakendusest mitut versiooni kõrvuti, kuna ei saa kuidagi teada, mis viimases versioonis katki läks, või ütleme, et mina kui veebiarendaja pean oma tööd erinevate brauseriversioonide all testima. Haiku lahendab esimese probleemi, kuid mitte teist. Värskendusi keeratakse tagasi, kuid ainult kogu süsteemi jaoks, näiteks mitut WebPositive'i või LibreOffice'i versiooni korraga käivitada on võimatu (minu teada).

Üks arendajatest kirjutab:

Põhimõtteliselt on põhjendus järgmine: kasutusjuhtum on nii haruldane, et selle optimeerimine pole mõttekas; selle käsitlemine erijuhtumina HaikuPortsis tundub enam kui vastuvõetav.

• Pean hoidma rakendusi seal, kus need mulle meeldivad, mitte käivituskettal. Mul saab sageli kettaruum otsa, mistõttu pean rakenduste (kõik versioonid, mille olen alla laadinud) salvestamiseks ühendama välise draivi või võrgukataloogi. Kui ühendan sellise draivi, pean rakendused käivitama topeltklõpsuga. Haiku salvestab pakettide vanu versioone, aga ma ei tea, kuidas neid välisele kettale teisaldada või hiljem sealt rakendusi käivitada.

Arendaja kommentaar:

Tehniliselt on see juba mount käsuga võimalik. Loomulikult teeme selle jaoks GUI niipea, kui meil on piisavalt huvitatud kasutajaid.

• Ma ei vaja miljoneid faile, mis on üle failisüsteemi laiali ja mida ma ise käsitsi hallata ei saa. Soovin iga rakenduse kohta ühte faili, mida saaksin hõlpsalt alla laadida, teisaldada, kustutada. Haiku puhul lahendatakse see probleem pakettide abil .hpkg, mis teisaldavad näiteks pythoni tuhandetest failidest ühte. Aga kui on näiteks pythonit kasutav Scribus, siis pean tegelema vähemalt kahe failiga. Ja ma pean hoolitsema selle eest, et säiliks nende versioonid, mis töötavad üksteisega.

AppImages'i mitu versiooni, mis töötavad kõrvuti samas Linuxis

Rakenduse arendaja vaatenurk

Vaatame rakenduste arendaja vaatevinklist:

• Tahan juhtida kogu kasutajakogemust. Ma ei taha sõltuda operatsioonisüsteemist, mis ütleb mulle, millal ja kuidas peaksin rakendused välja andma. Haiku võimaldab arendajatel töötada oma hpkg hoidlatega, kuid see tähendab, et kasutajad peavad need käsitsi seadistama, mis muudab idee "vähem atraktiivseks".
• Minu veebisaidil on allalaadimisleht, kus ma levitan .exe Windowsi jaoks, .dmg Macile ja .AppImage Linuxi jaoks. Või äkki tahan sellele lehele juurdepääsu raha teenida, kõik on võimalik? Mida ma peaksin sinna Haiku jaoks panema? Failist piisab .hpkg sõltuvustega ainult HaikuPortsist
• Minu tarkvara nõuab muu tarkvara konkreetseid versioone. Näiteks on teada, et Krita vajab Qt paigatud versiooni või Qt, mis on täpselt häälestatud Krita konkreetsele versioonile, vähemalt seni, kuni paigad Qt-sse tagasi lükatakse. Saate oma rakenduse jaoks oma Qt pakkida pakendisse .hpkg, kuid tõenäoliselt pole see teretulnud.

Tavaline rakenduse allalaadimise leht. Mida ma peaksin siia Haiku jaoks postitama?

Pakub komplekte (olemasolevad rakenduskataloogidena, nagu AppDir või .app Apple'i stiilis) ja/või pilte (tugevalt muudetud rakendusepiltide või .dmg Apple'ilt) rakendused on kasulik täiendus Haiku töölauakeskkonnale? Või lahjendab see tervikpilti ja viib killustumiseni ning lisab seetõttu keerukust? Olen rebenenud: ühest küljest põhineb Haiku ilu ja keerukus sellel, et millegi tegemiseks on tavaliselt üks viis, mitte palju. Teisest küljest on suurem osa kataloogide ja/või rakenduskomplektide infrastruktuurist juba paigas, nii et süsteem karjub, et ülejäänud paar protsenti paika loksuks.

Arendaja sõnul härra. waddlespllash

Linuxis nad (kataloogid ja rakenduskomplektid, - u. tõlkija) on tõenäoliselt süsteemsete probleemide tehniline lahendus. Haikus eelistame lihtsalt süsteemiprobleeme lahendada.

Mida sa arvad?

Enne kui vastad...

Oota, teeme kiire tegelikkuse kontrolli: tegelikult rakenduste kataloogid - juba osa Haikust:

Rakenduste kataloogid on Haikul juba olemas, kuid failihaldur neid veel ei toeta

Neid lihtsalt ei toetata nii hästi kui näiteks Macintoshi Finderit. Kui lahe oleks, kui QtCreatori kataloogi vasakus ülanurgas oleks "QtCreator" nimi ja ikoon, mis käivitaks rakenduse topeltklõpsu korral?

Ma juba natuke varem küsis:

Kas olete kindel, et saate oma kümne aasta vanuseid rakendusi täna käivitada, kui kõik rakenduste poed ja levitamishoidlad on need ja nende sõltuvused unustanud? Kas olete kindel, et pääsete oma praegusele töökohale ka tulevikus ligi?

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

Vastavalt hr. waddlesplash:

Jah, meil on vastus küsimusele: me lihtsalt toetame neid rakendusi nii kaua, kui vaja, kuni keegi suudab nende failivorminguid õigesti lugeda või pakkuda üks-ühele funktsioone. Meie pühendumus BeOS R5 rakenduste toetamisele Haikul on selle tõestuseks...

See on kindel!

Kuidas peaks Haiku tegutsema?

Kujutan ette hpkg, kataloogide ja rakenduste piltide rahulikku kooseksisteerimist:

• Süsteemitarkvara kasutamine .hpkg
• Kõige sagedamini kasutatava tarkvara jaoks (eriti nende jaoks, mis vajavad jooksva väljalaske ajakava), kasutage .hpkg (umbes 80% kõigist juhtudest)
• Mõned installitud kaudu .hpkg, saavad rakendused kasu, kui liiguvad rakenduste kataloogi infrastruktuuri (nt QtCreator): neid levitatakse kui .hpkg, nagu enne.

härra. waddlesplash kirjutab:

Kui teil on vaja ainult rakendusi vaadata /system/apps, selle asemel peaksime muutma töölauariba kataloogid kasutajate jaoks paremini hallatavaks, kuna /system/apps pole mõeldud kasutajatele regulaarseks avamiseks ja vaatamiseks (erinevalt MacOS-ist). Selliste olukordade jaoks on haikul erinev paradigma, kuid see variant on teoreetiliselt vastuvõetav.

• Haiku saab infrastruktuuri rakenduste piltide käitamiseks, tarkvara öiste, pidevate ja testversioonide jaoks, aga ka juhtudel, kui kasutaja soovib selle õigeks ajaks külmutada, privaat- ja sisetarkvara jaoks ning muudeks erikasutusjuhtudeks (umbes 20%) kõigist). Need pildid sisaldavad rakenduse käitamiseks vajalikke faile .hpkg, süsteemi poolt monteeritud ja pärast rakenduse valmimist - lahtiühendatud. (Võib-olla võiks failihaldur failid panna .hpkg rakenduse kujutistesse automaatselt või kasutaja soovil – noh, näiteks siis, kui lohistate rakenduse võrgukataloogi või välisesse draivi. See on lihtsalt laul! Õigemini luule – haiku.) Teisest küljest võib kasutaja soovida pildi sisu failidena installida.hpkg, misjärel neid uuendatakse ja töödeldakse samamoodi nagu oleks installitud läbi HaikuDepot... Peame ajurünnakut tegema).

Tsitaat hr. waddlesplash:

Rakenduste käivitamine välistest draividest või võrgukataloogidest võib olla kasulik. Ja lisades võimaluse seadistada rohkem "tsoone" pkgmani jaoks oleks kindlasti tore funktsioon.

Selline süsteem kasutaks ära hpkg, kataloogide ja rakenduste kujutised. Nad on üksikult head, kuid koos muutuvad nad võitmatuks.

Järeldus

Haikul on raamistik, mis pakub arvutile lihtsat ja keerukat kasutuskogemust ning ületab Linuxi personaalarvutite jaoks tavaliselt pakutava. Pakendi süsteem .hpkg on üks selline näide, kuid ka ülejäänud süsteem on läbimõeldud. Haikule tuleks aga kasuks korralik kataloogi- ja rakenduspildi tugi. Kuidas seda kõige paremini teha, tasub arutada inimestega, kes tunnevad Haikut, selle filosoofiat ja arhitektuuri minust palju paremini. Olen ju Haikuid kasutanud veidi üle nädala. Sellegipoolest usun ma, et Haiku disainerid, arendajad ja arhitektid saavad sellest värskest vaatenurgast kasu. Mul oleks vähemalt hea meel olla nende "sparingpartner". Mul on üle 10 aasta praktilist kogemust Linuxi rakenduste kataloogide ja pakettide alal ning ma sooviksin leida neile kasutust Haikus, mille jaoks need minu arvates sobivad ideaalselt. Minu pakutud võimalikud lahendused pole minu kirjeldatud probleemidele sugugi ainsad õiged ja kui Haiku meeskond otsustab leida teisi, elegantsemaid, olen ma selle poolt. Põhimõtteliselt mõtlen juba süsteemi loomise ideele hpkg veelgi hämmastavam, muutmata selle toimimisviisi. Selgub, et Haiku tiim oli paketihaldussüsteemi juurutades pikalt mõelnud rakenduspakettidele, kuid kahjuks läks (ma arvan) idee "aegunud". Ehk on aeg see taaselustada?

Proovi ise! Lõppude lõpuks pakub Haiku projekt loodud pilte DVD-lt või USB-lt käivitamiseks iga päev.
Kas teil on küsimusi? Kutsume teid venekeelsesse telegrammi kanal.

Vea ülevaade: Kuidas tulistada endale jalga C ja C++ keeles. Haiku OS retseptide kogu

Pärit autor tõlge: see on Haiku-teemalise sarja kaheksas ja viimane artikkel.

Artiklite loend: Esimene Teine kolmas Neljas Viies Kuues Seitsmes

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas hpkg süsteemi Linuxi portimine on mõttekas?

• Jah

• ei

• Juba rakendatud, kirjutan kommentaaridesse

20 kasutajat hääletas. 5 kasutajat jäi erapooletuks.

Allikas: www.habr.com