TL; DR: A all Haiku gael cefnogaeth briodol ar gyfer pecynnau cais, megis cyfeiriaduron cais (fel .app ar Mac) a/neu ddelweddau cymhwysiad (Linux AppImage)? Rwy'n meddwl y byddai hwn yn ychwanegiad teilwng sy'n haws ei weithredu'n gywir na systemau eraill gan fod y rhan fwyaf o'r seilwaith eisoes yn ei le.
Darganfyddais Haiku, system annisgwyl o dda. Wel, gan fy mod wedi bod â diddordeb mewn cyfeiriaduron a delweddau cymhwysiad ers tro (wedi fy ysbrydoli gan symlrwydd y Macintosh), nid yw'n syndod bod syniad wedi dod i fy meddwl ...
I gael dealltwriaeth lawn, fi yw crëwr ac awdur AppImage, fformat dosbarthu cymhwysiad Linux sy'n anelu at symlrwydd Mac ac yn rhoi rheolaeth lawn i awduron cymwysiadau a defnyddwyr terfynol (os ydych chi eisiau gwybod mwy, gweler и ).
Beth os gwnawn ni AppImage ar gyfer Haiku?
Gadewch i ni feddwl ychydig, yn hollol ddamcaniaethol: beth sydd angen ei wneud er mwyn cael , neu rywbeth tebyg, ar Haiku? Nid oes angen creu rhywbeth ar hyn o bryd, oherwydd mae'r system sydd eisoes yn bodoli yn Haiku yn gweithio'n rhyfeddol, ond byddai arbrawf dychmygol yn braf. Mae hefyd yn dangos soffistigedigrwydd Haiku, o'i gymharu ag amgylcheddau bwrdd gwaith Linux, lle mae pethau o'r fath yn ofnadwy o anodd (mae gen i'r hawl i ddweud hynny: rydw i wedi bod yn cael trafferth dadfygio ers 10 mlynedd).
Ar y Macintosh System 1, roedd pob cais yn ffeil ar wahân "a reolir" yn y Finder. Gan ddefnyddio AppImage rwy'n ceisio ail-greu'r un profiad defnyddiwr ar Linux.
Yn gyntaf, beth yw AppImage? Mae hon yn system ar gyfer rhyddhau ceisiadau trydydd parti (er enghraifft, ), caniatáu i gymwysiadau gael eu rhyddhau pryd a sut y dymunant: nid oes angen gwybod manylion gwahanol ddosbarthiadau, adeiladu polisïau neu adeiladu seilwaith, nid oes angen cefnogaeth cynnal a chadw, ac nid ydynt yn dweud wrth ddefnyddwyr beth (na) y gallant ei osod ar eu cyfrifiaduron. Dylid deall AppImage fel rhywbeth tebyg i becyn Mac yn y fformat .app y tu mewn i ddelwedd y ddisg .dmg. Y prif wahaniaeth yw nad yw ceisiadau'n cael eu copïo, ond yn aros y tu mewn i'r AppImage am byth, yn debyg iawn i becynnau Haiku .hpkg wedi ei osod, ac heb ei osod byth yn yr ystyr arferol.
Dros gyfnod o fwy na 10 mlynedd o fodolaeth, mae AppImage wedi ennill rhywfaint o apêl a phoblogrwydd: fe’i cymeradwywyd yn gyhoeddus gan Linus Torvalds ei hun, ac mae prosiectau cyffredin (er enghraifft, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) wedi ei fabwysiadu fel y brif ffordd. i ddosbarthu adeiladau parhaus neu nos, heb ymyrryd â chymwysiadau defnyddwyr sydd wedi'u gosod neu eu dadosod. Fodd bynnag, mae amgylcheddau bwrdd gwaith Linux a dosbarthiadau gan amlaf yn dal i lynu wrth y model dosbarthu traddodiadol, canolog yn seiliedig ar gynhalwyr a / neu hyrwyddo eu busnes menter eu hunain a / neu raglenni peirianneg yn seiliedig ar (RedHat, Fedora, GNOME) a (Canonaidd, Ubuntu). Mae'n dod .
Sut mae'n gweithio
- Mae pob AppImage yn cynnwys 2 ran: ELF clic dwbl bach (fel y'i gelwir.
runtime.c), ac yna delwedd system ffeiliau .
- Mae system ffeiliau SquashFS yn cynnwys llwyth tâl y rhaglen a phopeth sydd ei angen i'w redeg, na ellir yn y meddwl iawn ei ystyried yn rhan o'r gosodiad rhagosodedig ar gyfer pob system darged eithaf diweddar (dosbarthiad Linux). Mae hefyd yn cynnwys metadata, megis enw'r cais, eiconau, mathau MIME, ac ati, ac ati.
- Pan gaiff ei redeg gan y defnyddiwr, mae runtime yn defnyddio FUSE a squashfuse i osod y system ffeiliau, ac yna'n trin sy'n rhedeg rhywfaint o bwynt mynediad (aka AppRun) y tu mewn i'r AppImage wedi'i osod.
Nid yw'r system ffeiliau wedi'i gosod ar ôl i'r broses ddod i ben.
Mae popeth yn ymddangos yn syml.
Ac mae'r pethau hyn yn cymhlethu popeth:
- Gyda chymaint o amrywiaeth o ddosbarthiadau Linux, ni ellir galw unrhyw beth “yn y meddwl iawn” yn “rhan o'r gosodiad diofyn ar gyfer pob system darged newydd.” Rydym yn gweithio o gwmpas y mater hwn trwy adeiladu , sy'n eich galluogi i benderfynu beth fydd yn cael ei becynnu yn yr AppImage a beth fydd angen ei gymryd yn rhywle arall. Ar yr un pryd, rydym weithiau'n colli, er gwaethaf y ffaith bod popeth, yn gyffredinol, yn gweithio'n wych. Am y rheswm hwn, rydym yn argymell bod crewyr pecynnau yn profi AppImages ar bob system darged (dosbarthiadau).
- Rhaid i lwythi tâl rhaglenni fod yn rhai y gellir eu hail-leoli ar draws y system ffeiliau. Yn anffodus, mae gan lawer o gymwysiadau lwybrau absoliwt â chod caled i, er enghraifft, adnoddau i mewn
/usr/share. Mae angen trwsio hyn rywsut. Yn ogystal, rhaid i chi naill ai allforioLD_LIBRARY_PATH, neu drwsiorpathfel y gall y llwythwr ddod o hyd i lyfrgelloedd cysylltiedig. Mae gan y dull cyntaf ei anfanteision (sy'n cael eu goresgyn mewn ffyrdd cymhleth), ac mae'r ail yn syml yn feichus. - Y perygl UX mwyaf i ddefnyddwyr yw hynny Ffeil AppImage ar ôl ei lawrlwytho. Credwch neu beidio, mae hyn yn rhwystr gwirioneddol i rai. Mae'r angen i osod y darn gweithredadwyedd yn feichus hyd yn oed i ddefnyddwyr profiadol. Fel ateb, gwnaethom awgrymu gosod gwasanaeth bach sy'n monitro ffeiliau AppImage ac yn gosod eu darn gweithredadwyedd. Yn ei ffurf bur, nid dyma'r ateb gorau, gan na fydd yn gweithio allan o'r bocs. Nid yw dosbarthiadau Linux yn darparu'r gwasanaeth hwn, felly, mae defnyddwyr yn cael profiad gwael allan o'r bocs.
- Mae defnyddwyr Linux yn disgwyl i raglen newydd gael eicon yn y ddewislen cychwyn. Ni allwch ddweud wrth y system: “Edrychwch, mae yna gymhwysiad newydd, gadewch i ni weithio.” Yn lle hynny, yn ôl y fanyleb XDG, mae angen i chi gopïo'r ffeil
.desktopi'r lle iawn yn/usrar gyfer gosodiad system gyfan, neu mewn$HOMEar gyfer unigolyn. Mae angen gosod eiconau o feintiau penodol, yn unol â manyleb XDG, mewn mannau penodolusrneu$HOME, ac yna rhedeg gorchmynion yn yr amgylchedd gwaith i ddiweddaru'r storfa eicon, neu obeithio y bydd rheolwr yr amgylchedd gwaith yn ei ddarganfod ac yn canfod popeth yn awtomatig. Yr un peth â mathau MIME. Fel ateb, cynigir defnyddio'r un gwasanaeth, a fydd, yn ogystal â gosod y faner gweithredadwyedd, os oes eiconau, ac ati. yn AppImage, copïwch nhw o AppImage i'r lleoedd cywir yn ôl XDG. Pan gaiff ei ddileu neu ei symud, disgwylir i'r gwasanaeth glirio popeth. Wrth gwrs, mae yna wahaniaethau yn ymddygiad pob amgylchedd gwaith, mewn fformatau ffeiliau graffig, eu maint, lleoliadau storio a dulliau ar gyfer diweddaru caches, sy'n creu problem. Yn fyr, mae'r dull hwn yn fagwrfa. - Os nad yw'r uchod yn ddigon, nid oes eicon AppImage o hyd yn y rheolwr ffeiliau. Nid yw'r byd Linux wedi penderfynu gweithredu elficon eto (er gwaethaf и ), felly mae'n amhosibl ymgorffori'r eicon yn uniongyrchol i'r cais. Felly mae'n ymddangos nad oes gan gymwysiadau yn y rheolwr ffeiliau eu eiconau eu hunain (dim gwahaniaeth, AppImage neu rywbeth arall), dim ond yn y ddewislen cychwyn maen nhw. Fel ateb, rydym yn defnyddio mân-luniau, mecanwaith a ddyluniwyd yn wreiddiol i ganiatáu i reolwyr bwrdd gwaith ddangos delweddau rhagolwg mân-luniau o ffeiliau graffig fel eu heiconau. O ganlyniad, mae'r gwasanaeth ar gyfer gosod y darn gweithredadwyedd hefyd yn gweithio fel “miniaturizer”, gan greu ac ysgrifennu mân-luniau eicon i'r lleoliadau priodol
/usrи$HOME. Mae'r gwasanaeth hwn hefyd yn glanhau os caiff yr AppImage ei ddileu neu ei symud. Oherwydd y ffaith bod pob rheolwr bwrdd gwaith yn ymddwyn ychydig yn wahanol, er enghraifft, ym mha fformatau y mae'n derbyn eiconau, ym mha feintiau neu leoedd, mae hyn i gyd yn boenus iawn. - Yn syml, mae'r cymhwysiad yn damwain wrth gyflawni os bydd gwallau'n digwydd (er enghraifft, mae llyfrgell nad yw'n rhan o'r system sylfaen ac nad yw'n cael ei chyflenwi yn AppImage), ac nid oes unrhyw un yn dweud wrth y defnyddiwr yn y GUI beth yn union sy'n digwydd. Dechreuon ni fynd o gwmpas hyn trwy ddefnyddio ar y bwrdd gwaith, sy'n golygu bod angen i ni ddal gwallau o'r llinell orchymyn, eu trosi'n negeseuon sy'n cael eu deall gan ddefnyddwyr, sydd wedyn angen eu harddangos ar y bwrdd gwaith. Ac wrth gwrs, mae pob amgylchedd bwrdd gwaith yn eu trin ychydig yn wahanol.
- Ar hyn o bryd (Medi 2019 - nodyn cyfieithydd) nid wyf wedi dod o hyd i ffordd syml o ddweud wrth y system bod y ffeil
1.pngrhaid ei agor gan ddefnyddio Krita, a2.png- defnyddio GIMP.
Lleoliad storio ar gyfer manylebau traws-bwrdd gwaith a ddefnyddir yn , и yn freedesktop.org
Mae cyflawni lefel y soffistigedigrwydd sydd wedi'i wau'n ddwfn i amgylchedd gwaith Haiku yn anodd, os nad yn amhosibl, oherwydd y manylebau ar gyfer traws-bwrdd gwaith, yn ogystal â gweithredu rheolwyr bwrdd gwaith yn seiliedig ar y manylebau hyn. Er enghraifft, gallwn ddyfynnu un eicon Firefox system gyfan: mae'n debyg, nid oedd awduron XDG hyd yn oed yn meddwl y gallai defnyddiwr gael sawl fersiwn o'r un cymhwysiad wedi'i osod.
Eiconau ar gyfer gwahanol fersiynau o Firefox
Roeddwn i'n meddwl tybed beth allai'r byd Linux ei ddysgu gan Mac OS X i osgoi integreiddio'r system yn gyfan gwbl. Os oes gennych amser ac wedi gwneud hyn, gwnewch yn siŵr eich bod yn darllen yr hyn a ddywedodd Arnaud Gurdol, un o beirianwyr Mac OS X cyntaf:
Roeddem am wneud gosod y rhaglen mor hawdd â llusgo eicon y rhaglen o rywle (gweinydd, gyriant allanol) ar yriant eich cyfrifiadur. I wneud hyn, mae'r pecyn cais yn storio'r holl wybodaeth, gan gynnwys eiconau, fersiwn, y math o ffeil sy'n cael ei phrosesu, y math o gynlluniau URL y mae angen i'r system eu gwybod i brosesu'r cais. Mae hyn hefyd yn cynnwys gwybodaeth ar gyfer 'storfa ganolog' yng nghronfa ddata Gwasanaethau Eicon a Gwasanaethau Lansio. I gefnogi perfformiad, caiff cymwysiadau eu 'darganfod' mewn sawl man 'adnabyddus': y system a chyfeiriaduron Cymwysiadau defnyddiwr, a rhai eraill yn awtomatig os yw'r defnyddiwr yn llywio i'r Finder yn y cyfeiriadur sy'n cynnwys y rhaglen. Yn ymarferol, gweithiodd hyn yn dda iawn.
Apple WWDC 2000 sesiwn 144 - Mac OS X: ceisiadau pecynnu ac argraffu dogfennau.
Nid oes dim byd tebyg i'r seilwaith hwn ar benbyrddau Linux, felly rydym yn chwilio am atebion o amgylch y cyfyngiadau strwythurol yn y prosiect AppImage.
Ydy Haiku yn dod i'r adwy?
Ac un peth arall: mae llwyfannau Linux fel sail amgylcheddau bwrdd gwaith yn tueddu i fod mor dan-fanwl fel bod llawer o bethau sy'n eithaf syml mewn system stac lawn gyson yn rhwystredig o ddarniog a chymhleth yn Linux. Neilltuais adroddiad cyfan i faterion yn ymwneud â llwyfan Linux ar gyfer amgylcheddau bwrdd gwaith (cadarnhaodd datblygwyr gwybodus y bydd popeth yn aros fel hyn am amser hir iawn).
Fy adroddiad ar broblemau amgylcheddau bwrdd gwaith Linux yn 2018
Cyfaddefodd hyd yn oed Linus Torvalds mai darnio oedd y rheswm pam y methodd y syniad gweithle.
Braf gweld Haiku!
Mae Haiku yn gwneud popeth yn rhyfeddol o syml
Er mai'r dull naïf o "gludo" AppImage i Haiku yw ceisio adeiladu (yn bennaf runtime.c a gwasanaeth) ei gydrannau (a allai hyd yn oed fod yn bosibl!), ni fydd hyn yn rhoi llawer o fudd i Haiku. Oherwydd mewn gwirionedd, mae'r rhan fwyaf o'r problemau hyn yn cael eu datrys yn Haiku ac maent yn gysyniadol gadarn. Mae Haiku yn darparu'r union flociau adeiladu seilwaith system yr wyf wedi bod yn edrych amdanynt mewn amgylcheddau bwrdd gwaith Linux cyhyd ac ni allwn gredu nad oeddent yno. sef:
Credwch neu beidio, mae hyn yn rhywbeth na all llawer o ddefnyddwyr Linux ei oresgyn. Ar Haiku mae popeth yn cael ei wneud yn awtomatig!
- Mae ffeiliau ELF nad oes ganddynt ychydig gweithredadwyedd yn cael un yn awtomatig pan gânt eu clicio ddwywaith yn y rheolwr ffeiliau.
- Gall fod gan raglenni adnoddau adeiledig, fel eiconau, sy'n cael eu harddangos yn y rheolwr ffeiliau. Nid oes angen copïo criw o ddelweddau i gyfeiriaduron arbennig gydag eiconau, ac felly nid oes angen eu glanhau ar ôl dileu neu symud y rhaglen.
- Mae cronfa ddata ar gyfer cysylltu ceisiadau â dogfennau, nid oes angen copïo unrhyw ffeiliau ar gyfer hyn.
- Yn y lib/ cyfeiriadur wrth ymyl y ffeil gweithredadwy, chwilir llyfrgelloedd yn ddiofyn.
- Nid oes nifer o ddosbarthiadau ac amgylcheddau bwrdd gwaith; beth bynnag sy'n gweithio, mae'n gweithio ym mhobman.
- Nid oes modiwl ar wahân i'w redeg sy'n wahanol i'r cyfeiriadur Ceisiadau.
- Nid oes gan geisiadau lwybrau absoliwt i'w hadnoddau; mae ganddynt swyddogaethau arbennig ar gyfer pennu lleoliad amser rhedeg.
- Mae'r syniad o ddelweddau system ffeiliau cywasgedig wedi'i gyflwyno: dyma unrhyw becyn hpkg. Mae pob un ohonynt yn cael eu gosod gan y cnewyllyn.
- Mae pob ffeil yn cael ei hagor gan y rhaglen a'i creodd, oni bai eich bod yn nodi'n benodol fel arall. Pa mor cŵl yw hyn!
Dwy ffeil png. Sylwch ar y gwahanol eiconau sy'n nodi y byddant yn cael eu hagor gan wahanol gymwysiadau pan fyddant yn cael eu clicio ddwywaith. Sylwch hefyd ar y gwymplen "Open with:" lle gall y defnyddiwr ddewis cymhwysiad unigol. Pa mor syml!
Mae'n edrych fel bod llawer o'r baglau a'r atebion sy'n ofynnol gan AppImage ar Linux yn dod yn ddiangen ar Haiku, sydd â'r symlrwydd a'r soffistigedigrwydd yn greiddiol iddo sy'n ei wneud yn delio â'r rhan fwyaf o'n hanghenion.
Oes angen pecynnau ap ar Haiku wedi'r cyfan?
Mae hyn yn arwain at gwestiwn mawr. Pe bai'n drefn maint yn haws creu system fel AppImage ar Haiku nag ar Linux, a fyddai'n werth ei wneud? Neu a yw Haiku, gyda'i system becynnau hpkg, i bob pwrpas wedi dileu'r angen i ddatblygu syniad o'r fath? Wel, i ateb mae angen i ni edrych ar y cymhelliant y tu ôl i fodolaeth AppImages.
Safbwynt y defnyddiwr
Edrychwn ar ein defnyddiwr terfynol:
- Rwyf am osod cais heb ofyn am gyfrinair gweinyddwr (gwraidd). Does dim cysyniad o weinyddwr ar Haiku, mae gan y defnyddiwr reolaeth lawn gan mai system bersonol ydyw! (Mewn egwyddor, gallwch ddychmygu hyn yn y modd aml-chwaraewr, gobeithio y bydd y datblygwyr yn ei gadw'n syml)
- Rwyf am gael y fersiynau diweddaraf a mwyaf o gymwysiadau, heb aros iddynt ymddangos yn fy nosbarthiad (gan amlaf mae hyn yn golygu “byth”, o leiaf oni bai fy mod yn diweddaru'r system weithredu gyfan). Ar Haiku mae hyn yn cael ei "ddatrys" gyda datganiadau fel y bo'r angen. Mae hyn yn golygu ei bod hi'n bosibl cael y fersiynau diweddaraf a mwyaf o gymwysiadau, ond er mwyn gwneud hyn mae angen diweddaru gweddill y system yn gyson, gan ei droi'n “darged symudol” i bob pwrpas..
- Rwyf eisiau sawl fersiwn o'r un cymhwysiad ochr yn ochr, gan nad oes unrhyw ffordd i wybod beth a dorrwyd yn y fersiwn ddiweddaraf, neu, dywedwch, mae angen i mi, fel datblygwr gwe, brofi fy ngwaith o dan wahanol fersiynau o'r porwr. Mae Haiku yn datrys y broblem gyntaf, ond nid yr ail. Mae diweddariadau yn cael eu rholio yn ôl, ond dim ond ar gyfer y system gyfan; mae'n amhosib (hyd y gwn) rhedeg, er enghraifft, sawl fersiwn o WebPositive neu LibreOffice ar yr un pryd.
Mae un o'r datblygwyr yn ysgrifennu:
Yn ei hanfod y rhesymeg yw hyn: mae'r achos defnydd mor brin fel nad yw optimeiddio ar ei gyfer yn gwneud synnwyr; mae ei drin fel achos arbennig yn HaikuPorts yn ymddangos yn fwy na derbyniol.
- Mae angen i mi gadw apiau lle rwy'n eu hoffi, nid ar fy yriant cychwyn. Rwy'n rhedeg allan o ofod disg yn aml, felly mae angen i mi gysylltu gyriant allanol neu gyfeiriadur rhwydwaith i storio cymwysiadau (pob fersiwn yr wyf wedi'i lawrlwytho). Os byddaf yn cysylltu gyriant o'r fath, mae angen i mi lansio ceisiadau trwy glicio ddwywaith. Mae Haiku yn arbed hen fersiynau o becynnau, ond dydw i ddim yn gwybod sut i'w symud i yriant allanol, na sut i lansio ceisiadau oddi yno yn ddiweddarach.
Sylw datblygwr:
Yn dechnegol, mae hyn eisoes yn bosibl gyda'r gorchymyn mount. Wrth gwrs, byddwn yn gwneud GUI ar gyfer hyn cyn gynted ag y bydd gennym ddigon o ddefnyddwyr â diddordeb.
- Nid oes angen miliynau o ffeiliau arnaf wedi'u gwasgaru ar draws y system ffeiliau na allaf eu rheoli fy hun â llaw. Rwyf am gael un ffeil fesul cais y gallaf ei lawrlwytho'n hawdd, ei symud, ei dileu. Ar Haiku mae'r broblem hon yn cael ei datrys gan ddefnyddio pecynnau
.hpkg, sy'n trosglwyddo, er enghraifft, python, o filoedd o ffeiliau i mewn i un. Ond os oes, er enghraifft, Scribus yn defnyddio python, yna mae'n rhaid i mi ddelio ag o leiaf dwy ffeil. Ac mae'n rhaid i mi ofalu cadw fersiynau ohonyn nhw sy'n gweithio gyda'i gilydd.
Fersiynau lluosog o AppImages yn rhedeg ochr yn ochr ar yr un Linux
Safbwynt datblygwr cais
Gadewch i ni edrych o safbwynt datblygwr cais:
- Rwyf am reoli profiad y defnyddiwr cyfan. Nid wyf am ddibynnu ar system weithredu i ddweud wrthyf pryd a sut y dylwn ryddhau ceisiadau. Mae Haiku yn caniatáu i ddatblygwyr weithio gyda'u storfeydd hpkg eu hunain, ond mae hyn yn golygu y bydd yn rhaid i ddefnyddwyr eu gosod â llaw, sy'n gwneud y syniad yn "llai deniadol."
- Mae gen i dudalen lawrlwytho ar fy ngwefan lle dwi'n dosbarthu
.exear gyfer Windows,.dmgar gyfer Mac a.AppImagear gyfer Linux. Neu efallai fy mod am fanteisio ar fynediad i'r dudalen hon, a oes unrhyw beth yn bosibl? Beth ddylwn i ei roi yno ar gyfer Haiku? Mae'r ffeil yn ddigon.hpkggyda dibyniaethau yn unig o HaikuPorts - Mae angen fersiynau penodol o feddalwedd arall ar fy meddalwedd. Er enghraifft, mae'n hysbys bod Krita angen fersiwn glytiog o Qt, neu Qt sydd wedi'i fireinio i fersiwn benodol o Krita, o leiaf nes bod y clytiau'n cael eu gwthio yn ôl i Qt. Gallwch becynnu eich Qt eich hun ar gyfer eich cais mewn pecyn
.hpkg, ond yn fwyaf tebygol ni chroesawir hyn.
Tudalen lawrlwytho cais rheolaidd. Beth ddylwn i ei bostio yma ar gyfer Haiku?
Bydd bwndeli (sy'n bodoli fel cyfeiriaduron cais fel AppDir neu .app yn arddull Apple) a/neu ddelweddau (ar ffurf AppImages wedi'u haddasu'n fawr neu .dmg gan Apple) yn ychwanegiad defnyddiol i amgylchedd bwrdd gwaith Haiku? Neu a fydd yn gwanhau’r darlun cyfan ac yn arwain at ddarnio, ac felly’n ychwanegu cymhlethdod? Rwyf wedi fy rhwygo: ar y naill law, mae harddwch a soffistigeiddrwydd Haiku yn seiliedig ar y ffaith bod un ffordd o wneud rhywbeth fel arfer, yn hytrach na llawer. Ar y llaw arall, mae'r rhan fwyaf o'r seilwaith ar gyfer catalogau a/neu gyfresi cymwysiadau eisoes yn ei le, felly mae'r system yn galw am i'r ychydig y cant sy'n weddill ddod i'w lle.
Yn ôl y datblygwr
Ar Linux maen nhw (catalogau a chitiau cais, - tua. cyfieithydd) yn fwyaf tebygol o fod yn ateb technegol i broblemau systemig. Yn Haiku mae'n well gennym ddatrys problemau system yn unig.
Beth yw eich barn chi?
Cyn i chi ateb...
Arhoswch, gadewch i ni wneud gwiriad realiti cyflym: mewn gwirionedd cyfeiriaduron cais - eisoes yn rhan o Haiku:
Mae cyfeirlyfrau cymhwysiad eisoes yn bodoli ar Haiku, ond nid ydynt yn cael eu cefnogi eto yn y rheolwr ffeiliau
Nid ydynt yn cael eu cefnogi cystal â, dyweder, y Darganfyddwr Macintosh. Pa mor cŵl fyddai hi pe bai gan gyfeiriadur QtCreator enw ac eicon "QtCreator" yn y gornel chwith uchaf a lansiodd y cais pan gafodd ei glicio ddwywaith?
Ychydig yn gynharach yr wyf yn barod :
A ydych chi'n siŵr y gallwch chi redeg eich apiau degawd oed heddiw pan fydd yr holl siopau app a storfeydd dosbarthu wedi anghofio amdanyn nhw a'u dibyniaethau? A ydych yn hyderus y byddwch yn dal i allu cael mynediad at eich swydd bresennol yn y dyfodol?
A oes ateb eisoes gan Haiku, neu a all catalogau a bwndeli cais helpu yma? Rwy'n credu y gallant.
Yn ol Mr. sblash gwadlan:
Oes, mae gennym yr ateb i'r cwestiwn: yn syml, byddwn yn cefnogi'r cymwysiadau hyn cyhyd ag y bo angen nes bod rhywun yn gallu darllen eu fformatau ffeil yn y ffordd gywir neu ddarparu ymarferoldeb un-i-un. Mae ein hymrwymiad i gefnogi apiau BeOS R5 ar Haiku yn brawf o hyn...
Mae hynny'n sicr!
Pa gamau y dylai Haiku eu cymryd?
Gallaf ddychmygu cydfodolaeth heddychlon hpkg, cyfeiriaduron a delweddau cymhwysiad:
- Defnyddiau meddalwedd system
.hpkg - Ar gyfer y meddalwedd a ddefnyddir amlaf (yn enwedig y rhai sydd angen amserlennu datganiadau treigl), defnyddiwch
.hpkg(tua 80% o’r holl achosion) - Gosododd rhai trwy
.hpkg, bydd ceisiadau yn elwa o symud i seilwaith cyfeiriadur ceisiadau (ee QtCreator): byddant yn cael eu dosbarthu fel.hpkg, fel o'r blaen.
mr. mae waddlesplash yn ysgrifennu:
Os mai'r cyfan sydd ei angen arnoch yw gweld ceisiadau yn
/system/apps, yn lle hynny dylem wneud y cyfeiriaduron yn Deskbar yn fwy hylaw i ddefnyddwyr, ers hynny/system/appsni fwriedir iddo gael ei agor a'i weld yn rheolaidd gan ddefnyddwyr (yn wahanol i MacOS). Ar gyfer sefyllfaoedd o'r fath, mae gan Haiku batrwm gwahanol, ond mae'r opsiwn hwn, mewn egwyddor, yn dderbyniol.
- Mae Haiku yn derbyn y seilwaith ar gyfer rhedeg delweddau cymhwysiad, yn nosweithiol, yn barhaus ac yn adeiladau prawf o feddalwedd, yn ogystal ag ar gyfer achosion pan fydd y defnyddiwr am ei “rewi mewn pryd”, ar gyfer meddalwedd preifat a mewnol, ac achosion defnydd arbennig eraill (tua 20% o bawb). Mae'r delweddau hyn yn cynnwys y ffeiliau angenrheidiol i redeg y rhaglen
.hpkg, wedi'i osod gan y system, ac ar ôl i'r cais gael ei gwblhau - heb ei osod. (Efallai y gallai rheolwr ffeiliau roi ffeiliau.hpkgi mewn i ddelweddau cymhwysiad, yn awtomatig neu ar gais y defnyddiwr - wel, fel pan fyddwch chi'n llusgo cymhwysiad i gyfeiriadur rhwydwaith neu yriant allanol. Dim ond cân ydi hi! Neu yn hytrach, barddoniaeth - haiku.) Ar y llaw arall, efallai y bydd y defnyddiwr am osod cynnwys y ddelwedd ar ffurf ffeiliau.hpkg, ac ar ôl hynny byddant yn cael eu diweddaru a'u prosesu yn yr un ffordd â phe baent wedi'u gosod trwy HaikuDepot... Mae angen i ni daflu syniadau).
Dyfyniad gan Mr. sblash gwadlan:
Gall rhedeg rhaglenni o yriannau allanol neu gyfeiriaduron rhwydwaith fod yn ddefnyddiol. A byddai ychwanegu'r gallu i ffurfweddu mwy o "barthau" ar gyfer pkgman yn bendant yn nodwedd braf.
Byddai system o'r fath yn manteisio ar hpkg, cyfeiriaduron, a delweddau cymhwysiad. Maent yn dda yn unigol, ond gyda'i gilydd byddant yn dod yn anorchfygol.
Casgliad
Mae gan Haiku fframwaith sy'n darparu profiad defnyddiwr syml a soffistigedig ar gyfer y PC, ac mae'n mynd ymhell y tu hwnt i'r hyn a ddarperir yn nodweddiadol ar gyfer y PC Linux. System pecyn .hpkg yn un enghraifft o'r fath, ond mae gweddill y system hefyd wedi'i thrwytho â soffistigedigrwydd. Fodd bynnag, byddai Haiku yn elwa o gefnogaeth cyfeiriadur a delwedd briodol. Mae'n werth trafod y ffordd orau o wneud hyn gyda phobl sy'n adnabod Haiku, ei hathroniaeth a'i bensaernïaeth yn llawer gwell na fi. Wedi'r cyfan, dwi wedi bod yn defnyddio Haiku ers ychydig dros wythnos. Serch hynny, credaf y bydd dylunwyr, datblygwyr a phenseiri Haiku yn elwa o'r persbectif ffres hwn. O leiaf, byddwn yn hapus i fod yn “bartner cynhyrfus.” Mae gen i dros 10 mlynedd o brofiad ymarferol gyda chatalogau a bwndeli cymwysiadau Linux, a hoffwn ddod o hyd i ddefnydd ar eu cyfer yn Haiku, y credaf eu bod yn ffit perffaith ar eu cyfer. Nid yr atebion posibl yr wyf wedi'u cynnig yw'r unig rai o bell ffordd sy'n gywir ar gyfer y problemau yr wyf wedi'u disgrifio, ac os bydd tîm Haiku yn penderfynu dod o hyd i rai eraill, mwy cain, yr wyf i gyd ar ei gyfer. Yn y bôn, rydw i eisoes yn meddwl am y syniad o sut i wneud system hpkg hyd yn oed yn fwy anhygoel heb newid y ffordd y mae'n gweithio. Mae'n ymddangos bod tîm Haiku wedi bod yn meddwl am fwndeli cais ers amser maith wrth weithredu system rheoli pecynnau, ond yn anffodus (rwy'n meddwl) daeth y syniad yn "ddarfodedig". Efallai ei bod hi'n bryd ei adfywio?
Rhowch gynnig arni eich hun! Wedi'r cyfan, mae prosiect Haiku yn darparu delweddau ar gyfer cychwyn o DVD neu USB, wedi'u cynhyrchu .
Oes gennych chi unrhyw gwestiynau? Rydym yn eich gwahodd i'r Rwsieg eu hiaith .
Trosolwg gwall:
O cyfieithiad: dyma'r wythfed erthygl a'r olaf yn y gyfres am Haiku.
Rhestr o erthyglau:
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
A yw'n gwneud synnwyr i drosglwyddo'r system hpkg i Linux?
-
Oes
-
Dim
-
Ar waith eisoes, byddaf yn ysgrifennu yn y sylwadau
Pleidleisiodd 20 o ddefnyddwyr. Ataliodd 5 o ddefnyddwyr.
Ffynhonnell: hab.com