Lt; DR: Ar Haiku gali gauti tinkamą programų paketų, tokių kaip programų katalogai (pvz., .app „Mac“ sistemoje) ir (arba) programų atvaizdus („Linux“. AppImage)? Manau, kad tai būtų vertas papildymas, kurį lengviau teisingai įdiegti nei kitas sistemas, nes dauguma infrastruktūros jau yra.
Atradau Haiku – netikėtai gerą sistemą. Na, o kadangi seniai domiuosi katalogais ir taikomųjų programų vaizdais (įkvėptas Macintosh paprastumo), tai nenuostabu, kad į galvą šovė idėja...
Kad suprasčiau, esu „AppImage“ – „Linux“ programų platinimo formato, kuriuo siekiama Mac paprastumo ir suteikia visišką kontrolę programų autoriams bei galutiniams vartotojams, kūrėjas ir autorius (jei norite sužinoti daugiau, žr. и ).
Ką daryti, jei sukursime „AppImage“ Haiku?
Pamąstykime šiek tiek, grynai teoriškai: ką reikia padaryti, kad gautume , ar kažkas panašaus, Haiku? Nebūtina dabar ką nors kurti, nes Haiku jau egzistuojanti sistema veikia nuostabiai, bet būtų gražus įsivaizduojamas eksperimentas. Tai taip pat parodo Haiku rafinuotumą, palyginti su Linux darbalaukio aplinkomis, kur tokie dalykai yra siaubingai sunkūs (turiu teisę tai pasakyti: aš kovoju su derinimu 10 metų).
„Macintosh System 1“ sistemoje kiekviena programa buvo atskiras failas, „tvarkomas“ „Finder“. Naudodamas „AppImage“ bandau atkurti tą pačią vartotojo patirtį „Linux“.
Pirma, kas yra „AppImage“? Tai sistema, skirta trečiųjų šalių programoms (pvz., ), leidžianti programas išleisti kada ir kaip jie nori: nereikia žinoti įvairių paskirstymų specifikos, kurti strategijų ar kurti infrastruktūros, nereikia priežiūros paslaugų teikėjo palaikymo ir jie nenurodo vartotojams, ko (ne) gali įdiegti. savo kompiuteriuose. „AppImage“ turėtų būti suprantama kaip kažkas panašaus į „Mac“ paketą formatu .app disko vaizdo viduje .dmg. Pagrindinis skirtumas yra tas, kad programos nėra kopijuojamos, bet išlieka „AppImage“ viduje, panašiai kaip „Haiku“ paketai. .hpkg sumontuotas ir niekada neįdiegtas įprasta prasme.
Per daugiau nei 10 gyvavimo metų „AppImage“ įgijo tam tikrą patrauklumą ir populiarumą: pats Linusas Torvaldsas jai viešai pritarė, o bendri projektai (pavyzdžiui, „LibreOffice“, „Krita“, „Inkscape“, „Scribus“, „ImageMagick“) tapo pagrindiniu būdu. platinti nepertraukiamas arba nakties versijas, netrukdant įdiegtoms ar pašalintoms vartotojo programoms. Tačiau „Linux“ darbalaukio aplinkos ir paskirstymai dažniausiai vis dar laikosi tradicinio, centralizuoto prižiūrėtoju pagrįsto platinimo modelio ir (arba) reklamuoja savo įmonės verslą ir (arba) inžinerines programas, pagrįstas („RedHat“, „Fedora“, GNOME) ir (Canonical, Ubuntu). Ateina .
Kaip tai veikia
- Kiekvieną AppImage sudaro 2 dalys: mažas dukart spustelėjęs ELF (vadinamasis.
runtime.c), po kurio pateikiamas failų sistemos vaizdas .
- „SquashFS“ failų sistemoje yra programos naudingoji apkrova ir viskas, ko reikia jai paleisti, o tai protingai negalima laikyti numatytojo diegimo dalimi kiekvienai gana nesenai tikslinei sistemai („Linux“ platinimas). Jame taip pat yra metaduomenų, tokių kaip programos pavadinimas, piktogramos, MIME tipai ir kt.
- Kai paleidžia vartotojas, vykdymo laikas naudoja FUSE ir squashfuse failų sistemai prijungti, o tada tvarko tam tikro įėjimo taško (dar žinomo kaip AppRun) paleidimą prijungtoje AppImage.
Baigus procesą, failų sistema atjungiama.
Viskas atrodo paprasta.
Ir šie dalykai viską apsunkina:
- Esant tokiai įvairiai „Linux“ paskirstymui, nieko „tinkamo proto“ negalima pavadinti „kiekvienos naujos tikslinės sistemos numatytojo diegimo dalimi“. Mes išsprendžiame šią problemą statydami , leidžianti nustatyti, kas bus supakuota programoje „AppImage“, o ką reikės perkelti į kitą vietą. Tuo pačiu kartais pasiilgstame, nepaisant to, kad apskritai viskas veikia puikiai. Dėl šios priežasties paketų kūrėjams rekomenduojame išbandyti „AppImages“ visose tikslinėse sistemose (platinimuose).
- Programos naudingosios apkrovos turi būti perkeliamos visoje failų sistemoje. Deja, daugelis programų turi sunkiai užkoduotus absoliučiuosius kelius į, pavyzdžiui, išteklius
/usr/share. Tai reikia kažkaip sutvarkyti. Be to, turite arba eksportuotiLD_LIBRARY_PATH, arba pataisytirpathkad krautuvas galėtų rasti susijusias bibliotekas. Pirmasis metodas turi savo trūkumų (kurie įveikiami sudėtingais būdais), o antrasis yra tiesiog sudėtingas. - Didžiausias UX spąstas vartotojams yra tai „AppImage“ failas po atsisiuntimo. Tikėkite ar ne, kai kuriems tai yra tikra kliūtis. Poreikis nustatyti vykdomumo bitą yra sudėtingas net patyrusiems vartotojams. Kaip išeitį pasiūlėme įdiegti nedidelę paslaugą, kuri stebi „AppImage“ failus ir nustato jų paleidimo bitą. Gryna forma tai nėra geriausias sprendimas, nes jis neveiks iš dėžutės. „Linux“ paskirstymai neteikia šios paslaugos, todėl vartotojai turi blogą patirtį.
- Linux vartotojai tikisi, kad naujos programos paleisties meniu bus piktograma. Negalite pasakyti sistemai: „Žiūrėk, yra nauja programa, dirbkime“. Vietoj to, pagal XDG specifikaciją, turite nukopijuoti failą
.desktopį reikiamą vietą/usrvisos sistemos diegimui arba$HOMEindividualiam. Tam tikro dydžio piktogramos, atsižvelgiant į XDG specifikaciją, turi būti dedamos tam tikrose vietoseusrarba$HOME, o tada darbo aplinkoje paleiskite komandas, kad atnaujintumėte piktogramų talpyklą, arba tikėkitės, kad darbo aplinkos valdytojas tai išsiaiškins ir viską automatiškai aptiks. Tas pats su MIME tipais. Kaip išeitis, siūloma naudoti tą pačią paslaugą, kuri, be paleidimo vėliavėlės nustatymo, bus, jei yra piktogramų ir pan. programoje „AppImage“, nukopijuokite juos iš „AppImage“ į tinkamas vietas pagal XDG. Tikimasi, kad ištrynus ar perkėlus paslauga viską išvalys. Žinoma, skiriasi kiekvienos darbo aplinkos elgesys, grafinių failų formatai, jų dydžiai, saugojimo vietos ir talpyklų atnaujinimo būdai, todėl kyla problemų. Trumpai tariant, šis metodas yra ramentas. - Jei to nepakanka, failų tvarkyklėje vis tiek nėra AppImage piktogramos. „Linux“ pasaulis dar nenusprendė įdiegti „elficon“ (nepaisant и ), todėl piktogramos įterpti tiesiai į programą neįmanoma. Taigi išeina, kad programos failų tvarkyklėje neturi savo piktogramų (jokio skirtumo, AppImage ar dar kažkas), jos yra tik starto meniu. Kaip išeitį, naudojame miniatiūras – mechanizmą, kuris iš pradžių buvo sukurtas taip, kad darbalaukio valdytojai galėtų rodyti grafinių failų miniatiūrų peržiūros vaizdus kaip piktogramas. Vadinasi, vykdomumo bito nustatymo paslauga taip pat veikia kaip „miniatiūris“, kuria ir įrašo piktogramų miniatiūras į atitinkamas vietas.
/usrи$HOME. Ši paslauga taip pat atlieka valymą, jei „AppImage“ ištrinama arba perkeliama. Dėl to, kad kiekviena darbalaukio tvarkyklė elgiasi šiek tiek skirtingai, pavyzdžiui, kokiais formatais priima piktogramas, kokius dydžius ar vietas, visa tai yra tikrai skausminga. - Programa tiesiog užstringa vykdymo metu, jei įvyksta klaidų (pavyzdžiui, yra biblioteka, kuri nėra pagrindinės sistemos dalis ir nėra pateikta „AppImage“), o vartotojui GUI niekas nepasako, kas tiksliai vyksta. Mes pradėjome tai apeiti naudodami darbalaukyje, o tai reiškia, kad turime sugauti klaidas iš komandinės eilutės, konvertuoti jas į vartotojo suprantamus pranešimus, kurie vėliau turi būti rodomi darbalaukyje. Ir, žinoma, kiekviena darbalaukio aplinka juos tvarko šiek tiek skirtingai.
- Šiuo metu (2019 m. rugsėjo mėn. – vertėjo pastaba) neradau paprasto būdo pasakyti sistemai, kad failas
1.pngturi būti atidarytas naudojant Krita, ir2.png- naudojant GIMP.
Kelių darbalaukių specifikacijų, naudojamų saugojimo vieta , и yra freedesktop.org
Dėl specifikacijų sunku, o gal net neįmanoma pasiekti tokio sudėtingumo lygio, kuris yra giliai įaustas į Haiku darbo aplinką. skirtiems įvairiems darbalaukiams, taip pat darbalaukio tvarkytuvams, pagrįstiems šiomis specifikacijomis. Kaip pavyzdį galime pateikti vieną visos sistemos „Firefox“ piktogramą: matyt, XDG autoriai net nepagalvojo, kad vartotojas gali turėti kelias tos pačios programos versijas.
Įvairių „Firefox“ versijų piktogramos
Man buvo įdomu, ko „Linux“ pasaulis galėtų pasimokyti iš „Mac OS X“, kad nesugadintų sistemos integracijos. Jei turite laiko ir užsiimate tuo, būtinai perskaitykite, ką pasakė Arnaud Gurdol, vienas pirmųjų Mac OS X inžinierių:
Norėjome, kad programos įdiegimas būtų toks paprastas, kaip programos piktogramos vilkimas iš kažkur (serverio, išorinio disko) į kompiuterio diską. Norėdami tai padaryti, programos pakete saugoma visa informacija, įskaitant piktogramas, versiją, apdorojamo failo tipą, URL schemų tipą, kurią sistema turi žinoti, kad apdorotų programą. Tai taip pat apima „centrinės saugyklos“ informaciją „Icon Services“ ir „Launch Services“ duomenų bazėje. Kad būtų palaikomas našumas, programos yra „atrandamos“ keliose „gerai žinomose“ vietose: sistemos ir naudotojo programų kataloguose ir kai kuriuose kituose automatiškai, jei vartotojas naršo į Finder kataloge, kuriame yra programa. Praktiškai tai veikė labai gerai.
Apple WWDC 2000 sesija 144 – Mac OS X: programų pakavimas ir dokumentų spausdinimas.
„Linux“ staliniuose kompiuteriuose nėra nieko panašaus į šią infrastruktūrą, todėl ieškome būdų, kaip apeiti struktūrinius „AppImage“ projekto apribojimus.
Ar Haiku ateina į pagalbą?
Ir dar vienas dalykas: „Linux“ platformos, kaip darbalaukio aplinkos pagrindas, paprastai būna taip nepakankamai apibrėžtos, kad daugelis dalykų, kurie yra gana paprasti nuoseklioje pilnos krūvos sistemoje, yra varginančiai suskaidyti ir sudėtingi „Linux“. Visą ataskaitą skyriau problemoms, susijusioms su Linux platforma, skirta darbalaukio aplinkai (išmanantys kūrėjai patvirtino, kad viskas taip išliks labai ilgai).
Mano pranešimas apie „Linux“ darbalaukio aplinkų problemas 2018 m
Net Linusas Torvaldsas pripažino, kad darbo vietos idėja žlugo dėl fragmentacijos.
Malonu matyti Haiku!
Haiku viską daro nuostabiai paprastą
Nors naivus požiūris į „AppImage“ perkėlimą į Haiku yra tiesiog pabandyti sukurti (daugiausia runtime.c ir paslaugą) jo komponentus (tai gali būti net įmanoma!), Haiku tai neduos daug naudos. Nes iš tikrųjų dauguma šių problemų yra išspręstos Haiku ir yra konceptualiai pagrįstos. Haiku pateikia būtent sistemos infrastruktūros kūrimo blokus, kurių taip ilgai ieškojau Linux darbalaukio aplinkoje ir negalėjau patikėti, kad jų nėra. Būtent:
Tikėkite ar ne, daugelis Linux vartotojų to negali įveikti. Haiku viskas daroma automatiškai!
- ELF failai, neturintys vykdomojo bito, automatiškai jį gauna dukart spustelėjus failų tvarkyklėje.
- Programose gali būti integruotų išteklių, pvz., piktogramų, kurios rodomos failų tvarkyklėje. Nereikia kopijuoti krūvos vaizdų į specialius katalogus su piktogramomis, todėl nereikia jų išvalyti ištrynus ar perkėlus programą.
- Yra duomenų bazė programoms susieti su dokumentais, tam nereikia kopijuoti jokių failų.
- lib/ kataloge, esančiame šalia vykdomojo failo, bibliotekų ieškoma pagal numatytuosius nustatymus.
- Nėra daugybės platinimų ir darbalaukio aplinkų; viskas, kas veikia, veikia visur.
- Nėra atskiro modulio, skirto paleisti, kuris skiriasi nuo programų katalogo.
- Programos neturi įmontuotų absoliučių kelių į savo išteklius; jos turi specialias funkcijas, skirtas nustatyti vietą vykdymo metu.
- Buvo pristatyta suspaustų failų sistemos vaizdų idėja: tai yra bet koks hpkg paketas. Visi jie yra sumontuoti branduolio.
- Kiekvieną failą atidaro jį sukūrusi programa, nebent aiškiai nurodote kitaip. Kaip tai šaunu!
Du png failai. Atkreipkite dėmesį į skirtingas piktogramas, rodančias, kad dukart spustelėjus jas atidarys skirtingos programos. Taip pat atkreipkite dėmesį į išskleidžiamąjį meniu „Atidaryti naudojant:“, kuriame vartotojas gali pasirinkti atskirą programą. Kaip paprasta!
Panašu, kad daugelis „AppImage“ operacinėje sistemoje „Linux“ reikalingų ramentų ir sprendimo būdų tampa nebereikalingi „Haiku“, kurio esmė yra paprastumas ir rafinuotumas, todėl jis patenkina daugumą mūsų poreikių.
Ar visgi Haiku reikia programų paketų?
Tai veda prie didelio klausimo. Jei tokią sistemą kaip „AppImage“ sukurti „Haiku“ sistemoje būtų daug lengviau nei „Linux“, ar verta tai padaryti? O gal Haiku su hpkg paketų sistema veiksmingai pašalino poreikį plėtoti tokią idėją? Na, norėdami atsakyti, turime pažvelgti į „AppImages“ egzistavimo motyvus.
Vartotojo perspektyva
Pažvelkime į mūsų galutinį vartotoją:
- Noriu įdiegti programą neprašydamas administratoriaus (root) slaptažodžio. Haiku nėra administratoriaus sąvokos, vartotojas turi visišką valdymą, nes tai yra asmeninė sistema! (Iš esmės tai galite įsivaizduoti kelių žaidėjų režimu, tikiuosi, kad kūrėjai tai padarys paprastai)
- Noriu gauti naujausias ir geriausias programų versijas, nelaukdamas, kol jos pasirodys mano platinime (dažniausiai tai reiškia „niekada“, bent jau nebent atnaujinsiu visą operacinę sistemą). Haiku tai „išspręsta“ plaukiojančiais leidimais. Tai reiškia, kad galima gauti naujausias ir geriausias programų versijas, tačiau norint tai padaryti, reikia nuolat atnaujinti likusią sistemos dalį, efektyviai paverčiant ją „judančiu taikiniu“..
- Noriu kelių tos pačios programos versijų greta, nes nėra galimybės sužinoti, kas sugedo naujausioje versijoje, arba, tarkime, man, kaip žiniatinklio kūrėjui, reikia išbandyti savo darbą skirtingose naršyklės versijose. Haiku išsprendžia pirmąją problemą, bet ne antrą. Atnaujinimai atšaukiami, bet tik visai sistemai; neįmanoma (kiek žinau) vienu metu paleisti, pavyzdžiui, kelių WebPositive ar LibreOffice versijų.
Vienas iš kūrėjų rašo:
Iš esmės loginis pagrindas yra toks: naudojimo atvejis yra toks retas, kad optimizuoti jį nėra prasmės; traktuoti jį kaip ypatingą atvejį HaikuPorts atrodo daugiau nei priimtina.
- Turiu laikyti programas ten, kur jos man patinka, o ne paleisties diske. Man dažnai pritrūksta vietos diske, todėl turiu prijungti išorinį diską arba tinklo katalogą, kad galėčiau saugoti programas (visas versijas, kurias atsisiunčiau). Jei prijungiu tokį diską, man reikia, kad programos būtų paleistos dukart spustelėjus. „Haiku“ išsaugo senas paketų versijas, bet nežinau, kaip juos perkelti į išorinį diską arba kaip vėliau iš ten paleisti programas.
Kūrėjo komentaras:
Techniškai tai jau įmanoma naudojant komandą mount. Žinoma, kai tik turėsime pakankamai susidomėjusių vartotojų, sukursime GUI.
- Man nereikia milijonų failų, išsibarsčiusių po failų sistemą, kurių pats negaliu valdyti. Vienai programai noriu vieno failo, kurį galėčiau lengvai atsisiųsti, perkelti, ištrinti. Haiku ši problema išspręsta naudojant paketus
.hpkg, kurie perkelia, pavyzdžiui, python, iš tūkstančių failų į vieną. Bet jei yra, pavyzdžiui, „Scribus“ naudojant „python“, tada aš turiu susidoroti su mažiausiai dviem failais. Ir aš turiu pasirūpinti, kad išlaikyčiau jų versijas, kurios derėtų viena su kita.
Kelios „AppImages“ versijos, veikiančios viena šalia kitos toje pačioje „Linux“.
Programų kūrėjo perspektyva
Pažiūrėkime programų kūrėjo požiūriu:
- Noriu kontroliuoti visą vartotojo patirtį. Nenoriu priklausyti nuo operacinės sistemos, kuri man pasakytų, kada ir kaip turėčiau išleisti programas. „Haiku“ leidžia kūrėjams dirbti su savo „hpkg“ saugyklomis, tačiau tai reiškia, kad vartotojai turės jas nustatyti rankiniu būdu, todėl idėja tampa „mažiau patraukli“.
- Savo svetainėje, kurioje platinu, turiu atsisiuntimo puslapį
.exeskirta „Windows“,.dmgskirta Mac ir.AppImageskirta Linux. O gal noriu užsidirbti pinigų prieiga prie šio puslapio, viskas įmanoma? Ką turėčiau įdėti į Haiku? Failo užtenka.hpkgsu priklausomybėmis tik iš HaikuPorts - Mano programinei įrangai reikalingos konkrečios kitos programinės įrangos versijos. Pavyzdžiui, žinoma, kad Krita reikalauja pataisytos Qt versijos arba Qt, kuri būtų tiksliai suderinta su konkrečia Krita versija, bent jau tol, kol pataisos bus grąžintos į Qt. Savo programai skirtą Qt galite supakuoti į paketą
.hpkg, bet greičiausiai tai nėra sveikintina.
Įprastas programos atsisiuntimo puslapis. Ką turėčiau čia paskelbti Haiku?
Bus paketai (esami kaip programų katalogai, pvz., AppDir arba .app „Apple“ stiliumi) ir (arba) vaizdais (labai modifikuotų „AppImages“ arba .dmg iš Apple) programos yra naudingas Haiku darbalaukio aplinkos papildymas? O gal tai praskies visą vaizdą ir suskaidys, o tai padidins sudėtingumą? Esu sudraskyta: viena vertus, Haiku grožis ir įmantrumas grindžiamas tuo, kad dažniausiai yra vienas būdas ką nors padaryti, o ne daug. Kita vertus, didžioji dalis katalogų ir (arba) taikomųjų programų rinkinių infrastruktūros jau yra, todėl sistema šaukiasi, kad likę keli procentai atsidurtų savo vietoje.
Pasak kūrėjo
„Linux“ jie (katalogai ir programų rinkiniai, - apytiksl. vertėjas) greičiausiai yra techninis sisteminių problemų sprendimas. Haiku mes norime paprasčiausiai spręsti sistemos problemas.
Ką tu manai?
Prieš atsakant...
Palaukite, greitai patikrinkime tikrovę: iš tikrųjų programų katalogai - jau dalis Haiku:
Programų katalogai jau yra Haiku, bet dar nepalaikomi failų tvarkyklėje
Jie tiesiog nėra taip gerai palaikomi kaip, tarkime, „Macintosh Finder“. Kaip būtų šaunu, jei QtCreator katalogo viršutiniame kairiajame kampe būtų „QtCreator“ pavadinimas ir piktograma, paleidžianti programą dukart spustelėjus?
Aš jau šiek tiek anksčiau :
Ar tikrai galite paleisti savo dešimtmečio senumo programas šiandien, kai visos programų parduotuvės ir platinimo saugyklos pamiršo apie jas ir jų priklausomybes? Ar esate įsitikinęs, kad ateityje vis tiek galėsite dirbti dabartinį darbą?
Ar jau yra atsakymas iš Haiku, ar čia gali padėti katalogai ir programų paketai? Manau, kad jie gali.
Pasak p. waddlesplash:
Taip, mes turime atsakymą į klausimą: mes tiesiog palaikysime šias programas tiek, kiek reikės, kol kas nors galės tinkamai perskaityti jų failų formatus arba suteikti „vienas su vienu“ funkcionalumą. Mūsų įsipareigojimas palaikyti BeOS R5 programas Haiku yra to įrodymas...
Tai tikrai!
Kokių veiksmų turėtų imtis Haiku?
Įsivaizduoju taikų hpkg, katalogų ir programų vaizdų sambūvį:
- Sistemos programinės įrangos naudojimas
.hpkg - Dažniausiai naudojamai programinei įrangai (ypač tai, kuriai reikia suplanuoti nuolatinius leidimus), naudokite
.hpkg(maždaug 80% visų atvejų) - Kai kurie įdiegti per
.hpkg, programoms bus naudinga perkelti į programų katalogų infrastruktūrą (pvz., QtCreator): jos bus platinamos kaip.hpkg, kaip ir anksčiau.
Ponas. waddlesplash rašo:
Jei viskas, ko jums reikia, yra peržiūrėti programas
/system/apps, vietoj to turėtume padaryti Deskbar katalogus lengviau valdomus vartotojams, nes/system/appsnėra skirtas vartotojams reguliariai atidaryti ir peržiūrėti (skirtingai nei MacOS). Tokiose situacijose Haiku turi skirtingą paradigmą, tačiau teoriškai ši galimybė yra priimtina.
- „Haiku“ gauna infrastruktūrą programų vaizdams paleisti, naktiniams, nuolatiniams ir bandomiesiems programinės įrangos statymams, taip pat atvejams, kai vartotojas nori „laiku ją užšaldyti“, privačiai ir vidinei programinei įrangai bei kitiems specialiems naudojimo atvejams (apie 20 proc. iš visų). Šiuose vaizduose yra failai, reikalingi programai paleisti
.hpkg, sumontuotas sistemos, o užbaigus paraišką – išmontuotas. (Galbūt failų tvarkyklė galėtų įdėti failus.hpkgautomatiškai arba vartotojo prašymu į programos vaizdus, pvz., kai nutempsite programą į tinklo katalogą arba išorinį diską. Tai tik daina! O tiksliau, poezija – haiku.) Kita vertus, vartotojas gali norėti vaizdo turinį įdiegti failų pavidalu.hpkg, po to jie bus atnaujinami ir apdorojami taip pat, lyg būtų įdiegti per HaikuDepot... Reikia pasukti mintis).
Citata iš p. waddlesplash:
Gali būti naudinga paleisti programas iš išorinių diskų arba tinklo katalogų. O galimybė sukonfigūruoti daugiau pkgman „zonų“ tikrai būtų puiki funkcija.
Tokia sistema pasinaudotų hpkg, katalogų ir programų vaizdais. Jie yra geri atskirai, bet kartu jie taps nenugalimi.
išvada
„Haiku“ turi sistemą, kuri suteikia paprastą ir sudėtingą vartotojo patirtį kompiuteriui ir gerokai viršija tai, kas įprasta „Linux“ asmeniniam kompiuteriui. Pakuotės sistema .hpkg yra vienas iš tokių pavyzdžių, tačiau visa kita sistema taip pat persmelkta rafinuotumo. Tačiau Haiku praverstų tinkamas katalogų ir programų vaizdo palaikymas. Kaip geriausia tai padaryti, verta aptarti su žmonėmis, kurie Haiku, jo filosofiją ir architektūrą išmano daug geriau nei aš. Juk naudoju Haiku kiek daugiau nei savaitę. Nepaisant to, manau, kad Haiku dizaineriai, kūrėjai ir architektai turės naudos iš šios naujos perspektyvos. Bent jau būčiau laimingas galėdamas būti jų „sparingo partneriu“. Turiu daugiau nei 10 metų praktinės patirties dirbant su „Linux“ programų katalogais ir paketais ir norėčiau rasti jiems pritaikymą Haiku, kuriam, manau, jie puikiai tinka. Mano pasiūlyti galimi sprendimai jokiu būdu nėra vieninteliai teisingi mano aprašytoms problemoms spręsti, o jei Haiku komanda nusprendžia ieškoti kitų, elegantiškesnių, aš esu už. Iš esmės aš jau galvoju apie idėją, kaip sukurti sistemą hpkg dar nuostabiau nekeičiant veikimo būdo. Pasirodo, „Haiku“ komanda, diegdama paketų valdymo sistemą, ilgai galvojo apie programų paketus, bet deja (manau) idėja „paseno“. Gal laikas jį atgaivinti?
Išbandykite patys! Galų gale, Haiku projektas pateikia vaizdus, kuriuos galima paleisti iš DVD arba USB, sugeneruotus .
Ar turite kokių nors klausimų? Kviečiame į rusakalbių .
Klaidų apžvalga:
Nuo vertimas: tai aštuntas ir paskutinis straipsnis iš serijos apie Haiku.
Straipsnių sąrašas:
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Ar prasminga hpkg sistemą perkelti į Linux?
-
Taip
-
Ne
-
Jau įgyvendinta, parašysiu komentaruose
Balsavo 20 vartotojų. 5 vartotojai susilaikė.
Šaltinis: www.habr.com