TL; DR: Getur Haiku fengið viðeigandi stuðning fyrir forritapakka, svo sem forritaskrár (eins og .app á Mac) og/eða forritamyndum (Linux AppImage)? Ég held að þetta væri verðug viðbót sem er auðveldara í framkvæmd á réttan hátt en önnur kerfi þar sem flestir innviðir eru þegar til staðar.
Ég uppgötvaði Haiku, óvænt gott kerfi. Jæja, þar sem ég hef lengi haft áhuga á möppum og forritamyndum (innblásin af einfaldleika Macintosh), þá kemur það ekki á óvart að hugmynd kom upp í huga minn...
Fyrir fullan skilning er ég skapari og höfundur AppImage, Linux forritadreifingarsniðs sem miðar að Mac einfaldleika og veitir höfundum forrita og notendum fulla stjórn (ef þú vilt vita meira, sjáðu и ).
Hvað ef við gerum AppImage fyrir Haiku?
Hugsum aðeins, eingöngu fræðilega: hvað þarf að gera til að fá , eða eitthvað álíka, á Haiku? Það er ekki nauðsynlegt að búa til eitthvað núna, því kerfið sem þegar er til í Haiku virkar ótrúlega, en ímynduð tilraun væri fín. Það sýnir líka fágun Haiku, samanborið við Linux skjáborðsumhverfi, þar sem slíkir hlutir eru hræðilega erfiðir (ég hef rétt til að segja það: Ég hef verið að glíma við villuleit í 10 ár).
Á Macintosh System 1 var hvert forrit sér skrá "stýrt" í Finder. Með því að nota AppImage er ég að reyna að endurskapa sömu notendaupplifunina á Linux.
Í fyrsta lagi, hvað er AppImage? Þetta er kerfi til að gefa út forrit frá þriðja aðila (td. ), sem gerir kleift að gefa út forrit þegar og hvernig þau vilja: það er engin þörf á að vita sérkenni ýmissa dreifinga, byggja stefnur eða byggja upp innviði, engan viðhaldsstuðning er þörf og þau segja notendum ekki hvað (ekki) þeir geta sett upp á tölvum sínum. AppImage ætti að skilja sem eitthvað svipað og Mac pakka í sniðinu .app inni í diskmyndinni .dmg. Aðalmunurinn er sá að forrit eru ekki afrituð, heldur eru þau inni í AppImage að eilífu, svipað og Haiku pakkar .hpkg uppsettur og aldrei settur upp í venjulegum skilningi.
Í meira en 10 ára tilveru hefur AppImage öðlast nokkra aðdráttarafl og vinsældir: Linus Torvalds samþykkti það sjálfur opinberlega og algeng verkefni (til dæmis LibreOffice, Krita, Inkscape, Scribus, ImageMagick) hafa tekið það upp sem aðalleiðina. að dreifa samfelldum eða nætursmíðum, ekki trufla uppsett eða óuppsett notendaforrit. Hins vegar, Linux skrifborðsumhverfi og dreifingar halda sig oftast enn við hefðbundna, miðstýrða dreifingarlíkanið sem byggir á viðhaldsaðilum og/eða kynna eigið fyrirtæki og/eða verkfræðiforrit byggt á (RedHat, Fedora, GNOME) og (Canonical, Ubuntu). Það kemur .
Hvernig þetta allt virkar
- Hver AppImage inniheldur 2 hluta: lítið tvísmella ELF (svokallað.
runtime.c), fylgt eftir með skráarkerfismynd .
- SquashFS skráarkerfið inniheldur hleðslu forritsins og allt sem þarf til að keyra það, sem í réttum huga getur ekki talist hluti af sjálfgefna uppsetningu fyrir hvert frekar nýlegt markkerfi (Linux dreifing). Það inniheldur einnig lýsigögn, svo sem heiti forritsins, tákn, MIME-gerðir osfrv., osfrv.
- Þegar keyrt er af notandanum notar keyrslutími FUSE og squashfuse til að tengja skráarkerfið og sér síðan um að keyra einhvern inngangspunkt (aka AppRun) inni á uppsettu AppImage.
Skráarkerfið er aftengt eftir að ferlinu lýkur.
Allt virðist einfalt.
Og þessir hlutir flækja allt:
- Með svo fjölbreyttri Linux dreifingu er ekkert „í réttu huga“ hægt að kalla „hluti af sjálfgefna uppsetningu fyrir hvert nýtt markkerfi. Við vinnum í kringum þetta mál með því að byggja , sem gerir þér kleift að ákvarða hvað verður pakkað í AppImage og hvað þarf að taka með annars staðar. Á sama tíma söknum við stundum þrátt fyrir að almennt gangi allt frábærlega. Af þessum sökum mælum við með því að pakkaframleiðendur prófi AppImages á öllum markkerfum (dreifingum).
- Burðarhleðsla forrita verður að vera færanleg um skráarkerfið. Því miður hafa mörg forrit harðkóðaðar algerar leiðir til, til dæmis, auðlindir í
/usr/share. Þetta þarf að laga einhvern veginn. Að auki verður þú annað hvort að flytja útLD_LIBRARY_PATH, eða lagarpathsvo að hleðslutækið geti fundið tengd bókasöfn. Fyrri aðferðin hefur sína galla (sem er hægt að sigrast á á flókinn hátt) og sú síðari er einfaldlega fyrirferðarmikill. - Stærsta UX-gildran fyrir notendur er þessi AppImage skrá eftir niðurhal. Trúðu það eða ekki, þetta er algjör hindrun fyrir suma. Þörfin fyrir að stilla executability bita er fyrirferðarmikil jafnvel fyrir reynda notendur. Sem lausn mælum við með að setja upp litla þjónustu sem fylgist með AppImage skrám og stillir keyrslubita þeirra. Í hreinu formi er það ekki besta lausnin, þar sem það virkar ekki út úr kassanum. Linux dreifingar bjóða ekki upp á þessa þjónustu, þess vegna hafa notendur slæma reynslu úr kassanum.
- Linux notendur búast við að nýtt forrit hafi táknmynd í ræsingarvalmyndinni. Þú getur ekki sagt kerfinu: "Sjáðu, það er nýtt forrit, við skulum vinna." Í staðinn, samkvæmt XDG forskriftinni, þarftu að afrita skrána
.desktopá réttan stað í/usrfyrir uppsetningu um allt kerfið, eða í$HOMEfyrir einstakling. Tákn af ákveðnum stærðum, samkvæmt XDG forskrift, þarf að setja á ákveðnum stöðum íusreða$HOME, og keyrðu síðan skipanir í vinnuumhverfinu til að uppfæra táknskyndiminni, eða vona að vinnuumhverfisstjórinn komist að því og skynji allt sjálfkrafa. Sama með MIME gerðir. Til lausnar er lagt til að notast verði við sömu þjónustu, sem, auk þess að setja executability flag, mun, ef það eru tákn o.s.frv. í AppImage, afritaðu þá frá AppImage á rétta staði samkvæmt XDG. Þegar henni er eytt eða henni er hreyft er gert ráð fyrir að þjónustan hreinsi allt. Auðvitað er munur á hegðun hvers vinnuumhverfis, á myndrænu skráarsniði, stærðum þeirra, geymslustöðum og aðferðum til að uppfæra skyndiminni, sem skapar vandamál. Í stuttu máli er þessi aðferð hækja. - Ef ofangreint er ekki nóg er samt ekkert AppImage tákn í skráastjóranum. Linux heimurinn hefur ekki enn ákveðið að innleiða elficon (þrátt fyrir и ), svo það er ómögulegt að fella táknið beint inn í forritið. Þannig að það kemur í ljós að forrit í skráastjóranum eru ekki með eigin tákn (enginn munur, AppImage eða eitthvað annað), þau eru aðeins í upphafsvalmyndinni. Til lausnar erum við að nota smámyndir, kerfi sem var upphaflega hannað til að gera skjáborðsstjórum kleift að sýna smámyndaforskoðunarmyndir af grafískum skrám sem tákn. Þar af leiðandi virkar þjónustan til að stilla keyrslubitann einnig sem „miniaturizer“, býr til og skrifar smámyndir tákna á viðeigandi staði
/usrи$HOME. Þessi þjónusta framkvæmir einnig hreinsun ef AppImage er eytt eða færð. Vegna þess að hver skjáborðsstjóri hegðar sér aðeins öðruvísi, til dæmis í hvaða sniði hann tekur við táknum, í hvaða stærðum eða stöðum, er þetta allt mjög sársaukafullt. - Forritið hrynur einfaldlega við framkvæmd ef villur koma upp (til dæmis er bókasafn sem er ekki hluti af grunnkerfinu og er ekki til staðar í AppImage), og það er enginn að segja notandanum í GUI hvað nákvæmlega er að gerast. Við byrjuðum að komast í kringum þetta með því að nota á skjáborðinu, sem þýðir að við þurfum að ná villum úr skipanalínunni, breyta þeim í notendaskilaboð, sem síðan þurfa að birtast á skjáborðinu. Og auðvitað, hvert skrifborðsumhverfi meðhöndlar þá aðeins öðruvísi.
- Í augnablikinu (september 2019 - athugasemd þýðanda) hef ég ekki fundið einfalda leið til að segja kerfinu að skráin
1.pngverður að opna með Krita, og2.png- með því að nota GIMP.
Geymslustaður fyrir forskriftir yfir skrifborð notaðar í , и er freedesktop.org
Það er erfitt, ef ekki ómögulegt, að ná því fágunarstigi sem er djúpt ofið í Haiku vinnuumhverfið vegna forskriftanna fyrir þvert skrifborð, sem og útfærslur á skjáborðsstjórum byggðum á þessum forskriftum. Sem dæmi getum við nefnt eitt Firefox-tákn fyrir allt kerfið: greinilega héldu höfundar XDG ekki einu sinni að notandi gæti haft nokkrar útgáfur af sama forriti uppsettar.
Tákn fyrir mismunandi útgáfur af Firefox
Ég var að velta fyrir mér hvað Linux heimurinn gæti lært af Mac OS X til að forðast að klúðra kerfissamþættingu. Ef þú hefur tíma og ert í þessu, vertu viss um að lesa það sem Arnaud Gurdol, einn af fyrstu Mac OS X verkfræðingunum, sagði:
Við vildum gera uppsetningu forritsins eins auðvelt og að draga forritatáknið einhvers staðar frá (miðlara, ytri drif) yfir á tölvudrifið þitt. Til að gera þetta geymir forritapakkinn allar upplýsingar, þar á meðal tákn, útgáfu, skráargerð sem verið er að vinna úr, gerð vefslóðakerfa sem kerfið þarf að vita til að vinna úr umsókninni. Þetta felur einnig í sér upplýsingar um „miðlæga geymslu“ í Icon Services og Launch Services gagnagrunninum. Til að styðja við frammistöðu eru forrit 'uppgötvuð' á nokkrum 'velþekktum' stöðum: kerfis- og forritaskrám notenda, og sumum öðrum sjálfkrafa ef notandinn fer í Finder í möppunni sem inniheldur forritið. Í reynd virkaði þetta mjög vel.
Apple WWDC 2000 lota 144 - Mac OS X: pökkunarforrit og prentun skjala.
Það er ekkert eins og þessi innviði á Linux skjáborðum, svo við erum að leita að lausnum í kringum byggingartakmarkanir í AppImage verkefninu.
Er Haiku að koma til bjargar?
Og eitt enn: Linux pallar sem grunnur skjáborðsumhverfis hafa tilhneigingu til að vera svo vantilgreindir að margt sem er frekar einfalt í samræmdu fullstafla kerfi er pirrandi sundurleitt og flókið í Linux. Ég helgaði heila skýrslu málefnum tengdum Linux vettvangi fyrir skrifborðsumhverfi (fróðir verktaki staðfestu að allt mun vera svona í mjög langan tíma).
Skýrsla mín um vandamál Linux skrifborðsumhverfis árið 2018
Jafnvel Linus Torvalds viðurkenndi að sundrungin væri ástæðan fyrir því að hugmyndin um vinnusvæði mistókst.
Gaman að sjá Haiku!
Haiku gerir allt ótrúlega einfalt
Þó að barnaleg nálgun við að „flytja“ AppImage til Haiku sé einfaldlega að reyna að smíða (aðallega runtime.c og þjónustu) íhluti þess (sem gæti jafnvel verið mögulegt!), mun þetta ekki veita Haiku miklum ávinningi. Vegna þess að í raun eru flest þessi vandamál leyst í Haiku og eru huglæg. Haiku veitir nákvæmlega byggingareiningarnar kerfisins sem ég hef verið að leita að í Linux skjáborðsumhverfi svo lengi og gat ekki trúað að væru ekki til staðar. Nefnilega:
Trúðu það eða ekki, þetta er eitthvað sem margir Linux notendur geta ekki sigrast á. Á Haiku er allt gert sjálfkrafa!
- ELF skrár sem eru ekki með keyrslubita fá þær sjálfkrafa þegar tvísmellt er í skráastjóranum.
- Forrit geta haft innbyggð auðlindir, svo sem tákn, sem birtast í skráasafninu. Það er engin þörf á að afrita fullt af myndum í sérstakar möppur með táknum og því engin þörf á að hreinsa þær upp eftir að forritið hefur verið eytt eða flutt.
- Það er gagnagrunnur til að tengja forrit við skjöl, það er engin þörf á að afrita neinar skrár fyrir þetta.
- Í lib/ möppunni við hliðina á keyrsluskránni er sjálfgefið leitað í bókasöfnum.
- Það eru engar fjölmargar dreifingar og skjáborðsumhverfi; hvað sem virkar, virkar alls staðar.
- Það er engin sérstök eining til að keyra sem er frábrugðin forritaskránni.
- Forrit hafa ekki innbyggðar alger slóðir að auðlindum sínum; þau hafa sérstakar aðgerðir til að ákvarða staðsetningu á keyrslutíma.
- Hugmyndin um þjappaðar skráarkerfismyndir hefur verið kynnt: þetta er hvaða hpkg pakki sem er. Öll þau eru sett upp af kjarnanum.
- Hver skrá er opnuð af forritinu sem bjó hana til, nema þú tilgreinir annað sérstaklega. Hversu flott er þetta!
Tvær png skrár. Athugaðu mismunandi tákn sem gefa til kynna að þau verði opnuð af mismunandi forritum þegar tvísmellt er. Athugaðu einnig fellivalmyndina „Opna með:“ þar sem notandinn getur valið einstakt forrit. Hversu einfalt!
Það lítur út fyrir að margar hækjur og lausnir sem krafist er af AppImage á Linux verði óþarfar á Haiku, sem hefur einfaldleikann og fágunina í grunninn sem gerir það að verkum að það sinnir flestum þörfum okkar.
Þarf Haiku apppakka eftir allt saman?
Þetta leiðir til stórrar spurningar. Ef það væri á stærðargráðu auðveldara að búa til kerfi eins og AppImage á Haiku en á Linux, væri það þess virði að gera það? Eða hefur Haiku, með hpkg pakkakerfinu sínu, í raun eytt þörfinni á að þróa slíka hugmynd? Jæja, til að svara þurfum við að skoða hvatann á bak við tilvist AppImages.
Sjónarhorn notanda
Við skulum líta á endanotandann okkar:
- Ég vil setja upp forrit án þess að biðja um kerfisstjóra (rót) lykilorð. Það er engin hugmynd um stjórnanda á Haiku, notandinn hefur fulla stjórn þar sem það er persónulegt kerfi! (Í grundvallaratriðum geturðu ímyndað þér þetta í fjölspilunarham, ég vona að verktaki haldi því einfalt)
- Ég vil fá nýjustu og bestu útgáfur af forritum, án þess að bíða eftir að þær birtast í dreifingu minni (oftast þýðir þetta "aldrei", að minnsta kosti nema ég uppfæri allt stýrikerfið). Á Haiku er þetta "leyst" með fljótandi útgáfum. Þetta þýðir að það er hægt að fá nýjustu og bestu útgáfur af forritum, en til að gera þetta þarftu stöðugt að uppfæra restina af kerfinu og breyta því í raun í „hreyfanlegt skotmark“.
- Ég vil fá nokkrar útgáfur af sama forriti hlið við hlið, þar sem það er engin leið að vita hvað var bilað í nýjustu útgáfunni, eða, segjum, ég, sem vefhönnuður, þarf að prófa vinnuna mína undir mismunandi útgáfum vafrans. Haiku leysir fyrsta vandamálið, en ekki annað. Uppfærslur eru afturkallaðar, en aðeins fyrir allt kerfið; það er ómögulegt (eftir því sem ég best veit) að keyra til dæmis nokkrar útgáfur af WebPositive eða LibreOffice á sama tíma.
Einn af hönnuðunum skrifar:
Í meginatriðum eru rökin þessi: notkunartilvikið er svo sjaldgæft að það er ekki skynsamlegt að hagræða fyrir það; að meðhöndla það sem sérstakt tilvik í HaikuPorts virðist meira en ásættanlegt.
- Ég þarf að geyma öpp þar sem mér líkar við þau, ekki á ræsidrifinu mínu. Ég verð oft uppiskroppa með pláss, svo ég þarf að tengja utanáliggjandi drif eða netskrá til að geyma forrit (allar útgáfur sem ég hef hlaðið niður). Ef ég tengi svona drif þarf ég að ræsa forrit með því að tvísmella. Haiku vistar gamlar útgáfur af pökkum, en ég veit ekki hvernig ég á að færa þá yfir á utanáliggjandi drif, eða hvernig á að ræsa forrit þaðan síðar.
Ummæli þróunaraðila:
Tæknilega séð er þetta nú þegar mögulegt með mount skipuninni. Auðvitað munum við búa til GUI fyrir þetta um leið og við höfum nóg af áhugasömum notendum.
- Ég þarf ekki milljónir skráa á víð og dreif um skráarkerfið sem ég get ekki stjórnað handvirkt sjálfur. Ég vil eina skrá fyrir hvert forrit sem ég get auðveldlega halað niður, flutt, eytt. Á Haiku er þetta vandamál leyst með því að nota pakka
.hpkg, sem flytja, til dæmis, python, úr þúsundum skráa í eina. En ef það er til dæmis Scribus sem notar python, þá þarf ég að takast á við að minnsta kosti tvær skrár. Og ég verð að gæta þess að halda útgáfum af þeim sem vinna saman.
Margar útgáfur af AppImages keyra hlið við hlið á sama Linux
Sjónarhorn forritara
Við skulum líta frá sjónarhóli forritara:
- Ég vil stjórna allri notendaupplifuninni. Ég vil ekki treysta á stýrikerfi til að segja mér hvenær og hvernig ég ætti að gefa út forrit. Haiku gerir forriturum kleift að vinna með eigin hpkg geymslur, en þetta þýðir að notendur verða að setja þær upp handvirkt, sem gerir hugmyndina "minna aðlaðandi."
- Ég er með niðurhalssíðu á vefsíðunni minni þar sem ég dreifi
.exefyrir Windows,.dmgfyrir Mac og.AppImagefyrir Linux. Eða kannski vil ég afla tekna af aðgangi að þessari síðu, allt er mögulegt? Hvað ætti ég að setja þarna fyrir Haiku? Skráin er nóg.hpkgmeð háð eingöngu frá HaikuPorts - Hugbúnaðurinn minn þarf sérstakar útgáfur af öðrum hugbúnaði. Til dæmis er vitað að Krita krefst plástra útgáfu af Qt, eða Qt sem er fínstillt að ákveðna útgáfu af Krita, að minnsta kosti þar til plástrunum er ýtt aftur inn í Qt. Þú getur pakkað þínu eigin Qt fyrir forritið þitt í pakka
.hpkg, en líklega er þetta ekki velkomið.
Venjuleg niðurhalssíða fyrir forrit. Hvað ætti ég að setja hér fyrir Haiku?
Mun búnt (sem eru til sem forritaskrár eins og AppDir eða .app í Apple stíl) og/eða myndir (í formi mjög breyttra AppImages eða .dmg frá Apple) forrit gagnleg viðbót við Haiku skjáborðsumhverfið? Eða mun það þynna út heildarmyndina og leiða til sundrungar og þess vegna auka flækjustigið? Ég er rifinn: annars vegar byggist fegurð og fágun Haiku á því að það er yfirleitt ein leið til að gera eitthvað, frekar en margar. Á hinn bóginn eru flestir innviðir fyrir vörulista og/eða forritasvítur þegar til staðar, þannig að kerfið hrópar á að þau fáu prósent sem eftir eru falli á sinn stað.
Að sögn framkvæmdaraðila
Á Linux þeir (bæklingar og umsóknarsett, - u.þ.b. þýðandi) eru líklegast tæknileg lausn á kerfisbundnum vandamálum. Hjá Haiku viljum við einfaldlega leysa kerfisvandamál.
Hvað finnst þér?
Áður en þú svarar...
Bíddu, við skulum gera snögga raunveruleikaskoðun: í raun umsóknarskrár - þegar hluti af Haiku:
Forritaskrár eru þegar til á Haiku, en þær eru ekki enn studdar í skráastjóranum
Þeir eru bara ekki eins vel studdir og til dæmis Macintosh Finder. Hversu flott væri það ef QtCreator skráin væri með „QtCreator“ nafn og tákn í efra vinstra horninu, ræsir forritið þegar tvísmellt er?
Nokkru fyrr ég þegar :
Ertu viss um að þú getir keyrt áratugagömul forritin þín í dag þegar allar appabúðir og dreifingargeymslur hafa gleymt þeim og ósjálfstæði þeirra? Ertu viss um að þú munt enn geta fengið aðgang að núverandi starfi þínu í framtíðinni?
Er nú þegar svar frá Haiku, eða geta bæklingar og forritabúntar hjálpað hér? Ég held að þeir geti það.
Að sögn hr. waddlesplash:
Já, við höfum svarið við spurningunni: við munum einfaldlega styðja þessi forrit eins lengi og þörf krefur þar til einhver getur lesið skráarsniðin sín á réttan hátt eða boðið upp á einn-á-mann virkni. Skuldbinding okkar um að styðja BeOS R5 öpp á Haiku er sönnun þessa...
Það er viss!
Hvaða ráðstafanir ætti Haiku að grípa til?
Ég get ímyndað mér friðsamlega sambúð hpkg, möppum og forritamyndum:
- Kerfishugbúnaður notar
.hpkg - Fyrir mest notaða hugbúnaðinn (sérstaklega þann sem þarf að skipuleggja útgáfur), notaðu
.hpkg(um það bil 80% allra tilfella) - Sumir settir upp í gegnum
.hpkg, forrit munu njóta góðs af því að færa sig yfir í innviði forritaskrár (td QtCreator): þeim verður dreift sem.hpkg, eins og áður.
herra. waddlesplash skrifar:
Ef allt sem þú þarft er að skoða forrit í
/system/apps, í staðinn ættum við að gera möppurnar á Deskbar viðráðanlegri fyrir notendur, þar sem/system/appser ekki ætlað að vera reglulega opnað og skoðað af notendum (ólíkt MacOS). Fyrir slíkar aðstæður hefur Haiku aðra hugmynd, en þessi valkostur er fræðilega ásættanleg.
- Haiku fær innviði til að keyra forritamyndir, nætur-, samfellda og prufusmíði hugbúnaðar, svo og fyrir tilvik þar sem notandinn vill „frysta hann í tíma“, fyrir einka- og innri hugbúnað og önnur sérstök notkunartilvik (um 20% af öllu). Þessar myndir innihalda þær skrár sem nauðsynlegar eru til að keyra forritið
.hpkg, sett upp af kerfinu, og eftir að forritinu er lokið - ótengt. (Kannski gæti skráarstjóri sett skrár.hpkginn í forritamyndir, sjálfkrafa eða að beiðni notandans - eins og þegar þú dregur forrit í netskrá eða ytra drif. Þetta er bara lag! Eða réttara sagt, ljóð - haiku.) Á hinn bóginn gæti notandinn viljað setja upp innihald myndarinnar í formi skráa.hpkg, eftir það verða þau uppfærð og unnin á sama hátt og ef þau væru sett upp í gegnum HaikuDepot... Við þurfum að hugleiða).
Tilvitnun í hr. waddlesplash:
Það getur verið gagnlegt að keyra forrit frá ytri drifum eða netmöppum. Og að bæta við möguleikanum á að stilla fleiri "svæði" fyrir pkgman væri örugglega ágætur eiginleiki.
Slíkt kerfi myndi nýta sér hpkg, möppur og forritamyndir. Þeir eru góðir hver fyrir sig, en saman verða þeir ósigrandi.
Ályktun
Haiku er með ramma sem veitir einfalda og háþróaða notendaupplifun fyrir tölvuna og fer langt umfram það sem venjulega er til staðar fyrir Linux tölvuna. Pakkakerfi .hpkg er eitt slíkt dæmi, en restin af kerfinu er líka gegnsýrt af fágun. Hins vegar myndi Haiku njóta góðs af réttum stuðningi við möppu og forritamynd. Hvernig best er að gera þetta er þess virði að ræða við fólk sem þekkir Haiku, heimspeki þess og arkitektúr miklu betur en ég. Enda hef ég notað Haiku í rúma viku. Engu að síður tel ég að hönnuðir, verktaki og arkitektar Haiku muni njóta góðs af þessu ferska sjónarhorni. Að minnsta kosti væri ég ánægður með að vera „sparring félagi“ þeirra. Ég hef yfir 10 ára reynslu af Linux forritaskrám og búntum og mig langar að finna not fyrir þá í Haiku, sem ég held að þeir passi fullkomlega við. Mögulegu lausnirnar sem ég hef lagt til eru alls ekki þær einu réttu fyrir vandamálin sem ég hef lýst, og ef Haiku-teymið ákveður að finna aðrar og glæsilegri, þá er ég alveg til í það. Í grundvallaratriðum er ég nú þegar að hugsa um hugmyndina um hvernig eigi að búa til kerfi hpkg enn ótrúlegra án þess að breyta því hvernig það virkar. Það kemur í ljós að Haiku teymið hafði lengi velt fyrir sér forritabúntum við innleiðingu á pakkastjórnunarkerfi, en því miður (held ég) varð hugmyndin "úrelt". Kannski kominn tími til að endurvekja það?
Prófaðu það sjálfur! Þegar öllu er á botninn hvolft gefur Haiku verkefnið myndir til að ræsa af DVD eða USB, myndaðar .
Ertu með spurningar? Við bjóðum þér til rússneskumælandi .
Villuyfirlit:
Frá þýðing: þetta er áttunda og síðasta greinin í seríunni um Haiku.
Listi yfir greinar:
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Er skynsamlegt að flytja hpkg kerfið yfir á Linux?
-
Já
-
No
-
Þegar komið til framkvæmda mun ég skrifa í athugasemdirnar
20 notendur kusu. 5 notendur sátu hjá.
Heimild: www.habr.com