Ուրիշ բան. Haiku հավելվածների փաթեթներ:

TL. DRԿարո՞ղ է Հայկուն ստանալ համապատասխան աջակցություն հավելվածների փաթեթների համար, ինչպիսիք են հավելվածների գրացուցակները (օրինակ .app Mac-ում) և/կամ հավելվածի պատկերներ (Linux AppImage)? Կարծում եմ, որ սա արժանի հավելում կլինի, որն ավելի հեշտ է ճիշտ իրականացնել, քան մյուս համակարգերը, քանի որ ենթակառուցվածքների մեծ մասն արդեն տեղադրված է:

Մեկ շաբաթ առաջ Ես հայտնաբերեցի Հայկուն՝ անսպասելիորեն լավ համակարգ։ Դե, քանի որ ես վաղուց հետաքրքրված եմ դիրեկտորիաներով և հավելվածների պատկերներով (ոգեշնչված Macintosh-ի պարզությամբ), զարմանալի չէ, որ միտքս ծագեց...

Լրիվ հասկանալու համար ես AppImage-ի ստեղծողն ու հեղինակն եմ՝ Linux հավելվածների բաշխման ձևաչափ, որը նպատակ ունի Mac-ի պարզության համար և լիարժեք վերահսկողություն է տալիս հավելվածների հեղինակներին և վերջնական օգտագործողներին (եթե ցանկանում եք ավելին իմանալ, տես. Վիքիփեդիա, ազատ հանրագիտարան и փաստաթղթեր).

Իսկ եթե մենք AppImage պատրաստենք Հայկուի համար:

Եկեք մի փոքր մտածենք, զուտ տեսականորեն՝ ինչ է պետք անել, որպեսզի ստանանք AppImage- ը, կամ նման մի բան, Հայկուի վրա: Պետք չէ հենց հիմա ինչ-որ բան ստեղծել, քանի որ Հայկուում արդեն գոյություն ունեցող համակարգը զարմանալիորեն աշխատում է, բայց երևակայական փորձը լավ կլիներ։ Այն նաև ցույց է տալիս Haiku-ի բարդությունը՝ համեմատած Linux աշխատասեղանի միջավայրերի հետ, որտեղ նման բաներն ահավոր դժվար են (ես իրավունք ունեմ այդպես ասել. ես 10 տարի պայքարում եմ վրիպազերծման հետ):

Macintosh System 1-ում յուրաքանչյուր հավելված առանձին ֆայլ էր, որը «կառավարվում էր» Finder-ում: Օգտագործելով AppImage-ը, ես փորձում եմ վերստեղծել նույն օգտվողի փորձը Linux-ում:

Նախ, ինչ է AppImage-ը: Սա երրորդ կողմի հավելվածների թողարկման համակարգ է (օրինակ. Ultimaker Cure), թույլ տալով, որ հավելվածները թողարկվեն, երբ և ինչպես նրանք ցանկանում են. կարիք չկա իմանալու տարբեր բաշխումների առանձնահատկությունները, կառուցել քաղաքականություն կամ կառուցել ենթակառուցվածք, կարիք չկա սպասարկողի աջակցություն, և նրանք չեն ասում օգտվողներին, թե ինչ (ոչ) կարող են տեղադրել: իրենց համակարգիչների վրա: AppImage-ը պետք է հասկանալ որպես ձևաչափով Mac փաթեթի նման մի բան .app սկավառակի պատկերի ներսում .dmg. Հիմնական տարբերությունն այն է, որ հավելվածները չեն պատճենվում, այլ ընդմիշտ մնում են AppImage-ում, նույնը, ինչ Haiku փաթեթները: .hpkg տեղադրված է և երբեք չի տեղադրվել սովորական իմաստով:

Ավելի քան 10 տարվա գոյության ընթացքում AppImage-ը ձեռք է բերել որոշակի գրավչություն և ժողովրդականություն. Լինուս Տորվալդսն ինքը հրապարակայնորեն հավանություն է տվել դրան, իսկ ընդհանուր նախագծերը (օրինակ՝ LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ընդունել են այն որպես հիմնական միջոց։ շարունակական կամ գիշերային կառուցումներ տարածելու համար՝ չխոչընդոտելով տեղադրված կամ ապատեղադրված օգտատերերի հավելվածներին: Այնուամենայնիվ, Linux-ի աշխատասեղանի միջավայրերը և բաշխումները ամենից հաճախ դեռևս կառչում են ավանդական, կենտրոնացված սպասարկողի վրա հիմնված բաշխման մոդելից և/կամ խթանում են իրենց սեփական ձեռնարկատիրական բիզնեսը և/կամ ինժեներական ծրագրերը՝ հիմնված Flatpak (RedHat, Fedora, GNOME) և Շատ պարզ (Canonical, Ubuntu): Այն գալիս է ծիծաղելիորեն.

Ինչպես է ամեն ինչ աշխատում

• Յուրաքանչյուր AppImage պարունակում է 2 մաս՝ փոքր կրկնակի սեղմումով ELF (այսպես կոչված. runtime.c), որին հաջորդում է ֆայլային համակարգի պատկերը SquashFS.

• SquashFS ֆայլային համակարգը պարունակում է հավելվածի ծանրաբեռնվածությունը և այն գործարկելու համար անհրաժեշտ ամեն ինչ, որը ճիշտ մտքով չի կարող համարվել լռելյայն տեղադրման մաս յուրաքանչյուր բավականին վերջերս թիրախային համակարգի համար (Linux բաշխում): Այն նաև պարունակում է մետատվյալներ, ինչպիսիք են հավելվածի անվանումը, պատկերակները, MIME տեսակները և այլն, և այլն:

• Օգտատիրոջ կողմից գործարկվելիս Runtime-ն օգտագործում է FUSE-ը և squashfuse-ը՝ ֆայլային համակարգը տեղադրելու համար, այնուհետև կարգավորում է մուտքի որոշ կետ (aka AppRun) տեղադրված AppImage-ի ներսում:
  Գործընթացի ավարտից հետո ֆայլային համակարգը ապամոնտաժվում է:

Ամեն ինչ պարզ է թվում.

Եվ այս բաները բարդացնում են ամեն ինչ.

• Linux-ի նման բազմազան բաշխումներով ոչինչ «ճիշտ մտքում» չի կարելի անվանել «կանխադրված տեղադրման մաս յուրաքանչյուր նոր թիրախային համակարգի համար»: Մենք աշխատում ենք այս խնդրի շուրջ՝ կառուցելով բացառվող ցուցակ, որը թույլ է տալիս որոշել, թե ինչ է փաթեթավորվելու AppImage-ում և ինչ պետք է տեղափոխվի մեկ այլ տեղ: Ընդ որում, երբեմն կարոտում ենք, չնայած նրան, որ, ընդհանուր առմամբ, ամեն ինչ հիանալի է ստացվում։ Այդ իսկ պատճառով, մենք խորհուրդ ենք տալիս փաթեթ ստեղծողներին փորձարկել AppImages-ը բոլոր թիրախային համակարգերում (բաշխումներ):
• Հավելվածի օգտակար բեռները պետք է տեղափոխելի լինեն ֆայլային համակարգով մեկ: Ցավոք, շատ հավելվածներ ունեն կոշտ կոդավորված բացարձակ ուղիներ, օրինակ՝ ռեսուրսներ /usr/share. Սա ինչ-որ կերպ պետք է շտկել։ Բացի այդ, դուք պետք է կամ արտահանեք LD_LIBRARY_PATH, կամ ուղղել rpath որպեսզի բեռնիչը կարողանա գտնել հարակից գրադարաններ: Առաջին մեթոդն ունի իր թերությունները (որոնք հաղթահարվում են բարդ եղանակներով), իսկ երկրորդը պարզապես ծանրաբեռնված է։
• Օգտագործողների համար UX-ի ամենամեծ որոգայթը դա է սահմանել գործարկվող բիթ AppImage ֆայլը ներբեռնելուց հետո: Հավատացեք, թե ոչ, սա իսկական խոչընդոտ է ոմանց համար: Կատարելիության բիթը սահմանելու անհրաժեշտությունը դժվար է նույնիսկ փորձառու օգտվողների համար: Որպես լուծում, մենք առաջարկեցինք տեղադրել մի փոքրիկ ծառայություն, որը վերահսկում է AppImage ֆայլերը և սահմանում դրանց կատարողականության բիթը: Իր մաքուր տեսքով, դա լավագույն լուծումը չէ, քանի որ այն չի աշխատի տուփից դուրս: Linux-ի բաշխումները չեն տրամադրում այս ծառայությունը, հետևաբար, օգտատերերը վատ փորձ ունեն:
• Linux-ի օգտատերերն ակնկալում են, որ նոր հավելվածը գործարկման ընտրացանկում կունենա պատկերակ: Դուք չեք կարող համակարգին ասել. «Տեսեք, կա նոր հավելված, եկեք աշխատենք»: Փոխարենը, XDG-ի ճշգրտման համաձայն, դուք պետք է պատճենեք ֆայլը .desktop դեպի ճիշտ տեղում /usr ամբողջ համակարգի տեղադրման համար կամ ներսում $HOME անհատի համար. Որոշ չափերի պատկերակներ, ըստ XDG-ի բնութագրերի, պետք է տեղադրվեն որոշակի վայրերում usr կամ $HOMEև այնուհետև գործարկեք հրամաններ աշխատանքային միջավայրում՝ պատկերակների քեշը թարմացնելու համար, կամ հուսալ, որ աշխատանքային միջավայրի կառավարիչը կհասկանա դա և ավտոմատ կերպով կհայտնաբերի ամեն ինչ: Նույնը MIME տեսակների դեպքում: Որպես լուծում առաջարկվում է օգտագործել նույն ծառայությունը, որը, բացի կատարողականության դրոշը դնելուց, կկատարի, եթե կան պատկերակներ և այլն։ AppImage-ում, պատճենեք դրանք AppImage-ից ճիշտ տեղերում՝ ըստ XDG-ի: Երբ ջնջվի կամ տեղափոխվի, սպասվում է, որ ծառայությունը կջնջի ամեն ինչ: Իհարկե, կան տարբերություններ յուրաքանչյուր աշխատանքային միջավայրի վարքագծի մեջ՝ գրաֆիկական ֆայլերի ձևաչափերի, դրանց չափերի, պահեստավորման վայրերի և քեշերի թարմացման մեթոդների մեջ, ինչը խնդիր է ստեղծում։ Մի խոսքով, այս մեթոդը հենակ է:
• Եթե ​​վերը նշվածը բավարար չէ, ապա ֆայլերի կառավարիչում դեռ չկա AppImage պատկերակը: Linux-ի աշխարհը դեռ չի որոշել իրականացնել elficon-ը (չնայած քննարկում и իրականացումը), այնպես որ անհնար է պատկերակը տեղադրել անմիջապես հավելվածում: Այսպիսով, պարզվում է, որ ֆայլերի կառավարչի հավելվածները չունեն իրենց սեփական պատկերակները (տարբերություն չկա, AppImage կամ այլ բան), դրանք միայն մեկնարկի ընտրացանկում են: Որպես լուծում՝ մենք օգտագործում ենք մանրապատկերներ, մեխանիզմ, որն ի սկզբանե նախագծվել էր աշխատասեղանի կառավարիչներին թույլ տալու որպես պատկերակներ ցուցադրել գրաֆիկական ֆայլերի մանրապատկերների նախադիտման պատկերները: Հետևաբար, կատարողականության բիթը կարգավորելու ծառայությունը նույնպես աշխատում է որպես «մինիատորիզատոր»՝ ստեղծելով և գրելով պատկերակների մանրապատկերներ համապատասխան վայրերում։ /usr и $HOME. Այս ծառայությունը նաև մաքրում է, եթե AppImage-ը ջնջվի կամ տեղափոխվի: Շնորհիվ այն բանի, որ աշխատասեղանի յուրաքանչյուր մենեջեր իրեն մի փոքր այլ կերպ է պահում, օրինակ, թե ինչ ձևաչափերով է ընդունում պատկերակները, ինչ չափերի կամ վայրերում, այս ամենը իսկապես ցավալի է:
• Հավելվածը պարզապես խափանում է կատարման ժամանակ, եթե սխալներ են տեղի ունենում (օրինակ, կա գրադարան, որը բազային համակարգի մաս չէ և չի տրամադրվում AppImage-ում), և ոչ ոք չկա, որ օգտագործողին ասի GUI-ում, թե կոնկրետ ինչ է տեղի ունենում: Մենք սկսեցինք շրջանցել սա՝ օգտագործելով ծանուցումներ աշխատասեղանի վրա, ինչը նշանակում է, որ մենք պետք է որսալ սխալները հրամանի տողից, դրանք վերածել օգտագործողի կողմից հասկացված հաղորդագրությունների, որոնք այնուհետև պետք է ցուցադրվեն աշխատասեղանին: Եվ, իհարկե, յուրաքանչյուր աշխատասեղանի միջավայր դրանք մի փոքր այլ կերպ է վերաբերվում:
• Այս պահին (սեպտեմբեր 2019 - թարգմանչի նշում) ես չեմ գտել համակարգին ասելու պարզ միջոց, որ ֆայլը 1.png պետք է բացվի Krita-ի միջոցով և 2.png - օգտագործելով GIMP:

Պահպանման վայրը՝ կիրառվող միջսեղանային բնութագրերի համար GNOME- ը, KDE и Xfce freedesktop.org-ն է

Բարդության մակարդակի հասնելը, որը խորապես հյուսված է Հայկուի աշխատանքային միջավայրում, դժվար է, եթե ոչ անհնար, տեխնիկական բնութագրերի պատճառով: XDG freedesktop.org-ից խաչաձև աշխատասեղանի համար, ինչպես նաև այս բնութագրերի հիման վրա աշխատասեղանի կառավարիչների իրականացում: Որպես օրինակ, մենք կարող ենք մեջբերել մեկ համակարգային Firefox պատկերակ. ըստ երևույթին, XDG-ի հեղինակները չեն էլ մտածել, որ օգտատերը կարող է տեղադրել նույն հավելվածի մի քանի տարբերակ:

Սրբապատկերներ Firefox-ի տարբեր տարբերակների համար

Ես մտածում էի, թե Linux-ի աշխարհը ինչ կարող է սովորել Mac OS X-ից, որպեսզի խուսափի համակարգի ինտեգրումը խաթարելուց: Եթե ​​ժամանակ ունեք և զբաղվում եք դրանով, անպայման կարդացեք, թե ինչ է ասել Արնաուդ Գուրդոլը՝ Mac OS X-ի առաջին ինժեներներից մեկը.

Մենք ցանկանում էինք հավելվածի տեղադրումը հեշտացնել, ինչպես հավելվածի պատկերակը ինչ-որ տեղից (սերվեր, արտաքին սկավառակ) ձեր համակարգչի սկավառակի վրա քաշելը: Դա անելու համար հավելվածի փաթեթը պահպանում է ամբողջ տեղեկատվությունը, ներառյալ պատկերակները, տարբերակը, մշակվող ֆայլի տեսակը, URL սխեմաների տեսակները, որոնք համակարգը պետք է իմանա հավելվածը մշակելու համար: Սա նաև ներառում է «կենտրոնական պահեստավորման» մասին տեղեկությունները «Icon Services» և «Launch Services» տվյալների բազայում: Արդյունավետության ապահովման համար հավելվածները «հայտնաբերվում» են մի քանի «հայտնի» վայրերում՝ համակարգի և օգտագործողի հավելվածների գրացուցակներում, և որոշ այլ ավտոմատ կերպով, եթե օգտատերը նավարկվում է դեպի Finder հավելվածը պարունակող գրացուցակում: Գործնականում սա շատ լավ աշխատեց:

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 նիստ 144 - Mac OS X. փաթեթավորման հավելվածներ և փաստաթղթերի տպում:

Linux-ի աշխատասեղանների վրա այս ենթակառուցվածքի նման ոչինչ չկա, ուստի մենք լուծումներ ենք փնտրում AppImage նախագծի կառուցվածքային սահմանափակումների շուրջ:

Արդյո՞ք Հայկուն օգնության է հասնում:

Եվ ևս մեկ բան. Linux պլատֆորմները, որպես աշխատասեղանի միջավայրերի հիմք, հակված են այնքան թերճշգրտված լինելու, որ շատ բաներ, որոնք բավականին պարզ են հետևողական ամբողջական փաթեթային համակարգում, հիասթափեցնող մասնատված և բարդ են Linux-ում: Ես մի ամբողջ զեկույց նվիրեցի աշխատասեղանի միջավայրերի համար Linux պլատֆորմի հետ կապված խնդիրներին (բանիմաց մշակողները հաստատեցին, որ ամեն ինչ այդպես կմնա շատ երկար ժամանակ):

Իմ զեկույցը Linux աշխատասեղանի միջավայրերի խնդիրների մասին 2018 թ

Նույնիսկ Լինուս Տորվալդսը խոստովանեց, որ աշխատանքային տարածքի գաղափարը ձախողվել է մասնատման պատճառով:

Հաճելի է տեսնել Հայկուն:

Հայկուն ամեն ինչ զարմանալիորեն պարզ է դարձնում

Թեև AppImage-ը Haiku-ին «փոխադրելու» միամիտ մոտեցումն այն է, որ պարզապես փորձենք կառուցել (հիմնականում runtime.c և սպասարկում) դրա բաղադրիչները (ինչը նույնիսկ հնարավոր է), սա մեծ օգուտ չի բերի Haiku-ին: Որովհետև իրականում այդ խնդիրների մեծ մասը լուծված է Հայկուում և կոնցեպտուալ առումով հիմնավորված է: Haiku-ն ապահովում է հենց համակարգի ենթակառուցվածքի կառուցման բլոկները, որոնք ես փնտրում էի Linux-ի աշխատասեղանի միջավայրերում այդքան երկար և չէի հավատում, որ այնտեղ չկան: Այսինքն:

Հավատացեք, թե ոչ, սա մի բան է, որը շատ Linux օգտվողներ չեն կարող հաղթահարել: Haiku-ում ամեն ինչ արվում է ավտոմատ կերպով:

• ELF ֆայլերը, որոնք չունեն կատարողականության բիթ, ավտոմատ կերպով ստանում են այն ֆայլերի կառավարիչում կրկնակի սեղմելիս:
• Հավելվածները կարող են ունենալ ներկառուցված ռեսուրսներ, ինչպիսիք են պատկերակները, որոնք ցուցադրվում են ֆայլերի կառավարիչում: Կարիք չկա պատկերների մի փունջ պատճենել հատուկ գրացուցակներում պատկերակներով, և, հետևաբար, կարիք չկա դրանք մաքրել հավելվածը ջնջելուց կամ տեղափոխելուց հետո:
• Կա տվյալների բազա՝ հավելվածները փաստաթղթերի հետ կապելու համար, դրա համար որևէ ֆայլ պատճենելու կարիք չկա։
• Գործարկվող ֆայլի կողքին գտնվող lib/ գրացուցակում գրադարանները որոնվում են լռելյայնորեն:
• Չկան բազմաթիվ բաշխումներ և աշխատասեղանի միջավայրեր, ինչ էլ որ աշխատում է, աշխատում է ամենուր:
• Գործարկման առանձին մոդուլ չկա, որը տարբերվում է Applications գրացուցակից:
• Հավելվածները չունեն ներկառուցված բացարձակ ուղիներ դեպի իրենց ռեսուրսները, նրանք ունեն հատուկ գործառույթներ՝ գործարկման ժամանակ գտնվելու վայրը որոշելու համար:
• Ներդրվել է սեղմված ֆայլային համակարգի պատկերների գաղափարը. սա ցանկացած hpkg փաթեթ է: Դրանք բոլորը մոնտաժված են միջուկով:
• Յուրաքանչյուր ֆայլ բացվում է այն ստեղծած հավելվածի կողմից, եթե այլ բան հստակորեն չնշեք: Ինչքան լավ է սա:

Երկու png ֆայլ: Նշեք տարբեր պատկերակները, որոնք ցույց են տալիս, որ դրանք կբացվեն տարբեր հավելվածների կողմից, երբ կրկնակի սեղմեք: Նկատի ունեցեք նաև «Բացել հետ.» բացվող ընտրացանկը, որտեղ օգտատերը կարող է ընտրել առանձին հավելված: Ինչքան պարզ։

Կարծես թե AppImage-ի կողմից Linux-ում պահանջվող շատ հենակներ և լուծումներ անհարկի են դառնում Haiku-ում, որն իր հիմքում ունի պարզությունն ու բարդությունը, որը ստիպում է նրան բավարարել մեր կարիքների մեծ մասը:

Ի վերջո, Հայկուն հավելվածների փաթեթների կարիք ունի՞:

Սա հանգեցնում է մեծ հարցի. Եթե ​​Haiku-ում AppImage-ի նման համակարգ ստեղծելը ավելի հեշտ լիներ, քան Linux-ում, արժե՞ արդյոք անել: Թե՞ Haiku-ն իր hpkg փաթեթային համակարգով արդյունավետորեն վերացրել է նման գաղափար մշակելու անհրաժեշտությունը: Դե, պատասխանելու համար մենք պետք է նայենք AppImages-ի գոյության դրդապատճառին:

Օգտագործողի տեսակետը

Եկեք նայենք մեր վերջնական օգտագործողին.

• Ես ուզում եմ հավելված տեղադրել առանց ադմինիստրատորի (արմատային) գաղտնաբառ խնդրելու: Haiku-ում ադմինիստրատոր հասկացություն չկա, օգտատերը լիովին վերահսկում է, քանի որ դա անհատական ​​համակարգ է: (Սկզբունքորեն, դուք կարող եք պատկերացնել սա բազմախաղացող ռեժիմում, հուսով եմ, որ մշակողները դա պարզ կպահեն)
• Ես ուզում եմ ստանալ հավելվածների վերջին և լավագույն տարբերակները՝ չսպասելով, որ դրանք հայտնվեն իմ բաշխման մեջ (առավել հաճախ դա նշանակում է «երբեք», համենայն դեպս, եթե ես թարմացնեմ ամբողջ օպերացիոն համակարգը): Հայկուի վրա դա «լուծվում է» լողացող թողարկումներով։ Սա նշանակում է, որ հնարավոր է ստանալ հավելվածների վերջին և լավագույն տարբերակները, սակայն դա անելու համար հարկավոր է անընդհատ թարմացնել համակարգի մնացած մասը՝ այն արդյունավետորեն վերածելով «շարժվող թիրախի»:.
• Ես ուզում եմ նույն հավելվածի մի քանի տարբերակներ կողք կողքի, քանի որ ոչ մի կերպ հնարավոր չէ իմանալ, թե ինչ է կոտրվել վերջին տարբերակում, կամ, ասենք, ես, որպես վեբ ծրագրավորող, պետք է փորձարկեմ իմ աշխատանքը բրաուզերի տարբեր տարբերակների տակ: Հայկուն լուծում է առաջին խնդիրը, բայց ոչ երկրորդը։ Թարմացումները հետ են վերադարձվում, բայց միայն ամբողջ համակարգի համար, անհնար է (որքան գիտեմ) գործարկել, օրինակ, WebPositive-ի կամ LibreOffice-ի մի քանի տարբերակներ միաժամանակ:

Մշակողներից մեկը գրում է.

Ըստ էության, հիմնավորումը սա է. օգտագործման դեպքն այնքան հազվադեպ է, որ դրա համար օպտիմալացնելն իմաստ չունի. HaikuPorts-ում այն ​​որպես հատուկ դեպք դիտարկելը ավելի քան ընդունելի է թվում:

• Ես պետք է հավելվածները պահեմ այնտեղ, որտեղ ինձ դուր են գալիս, այլ ոչ թե իմ գործարկման սկավառակում: Ինձ հաճախ սպառվում է սկավառակի տարածքը, ուստի պետք է միացնեմ արտաքին սկավառակ կամ ցանցային գրացուցակ՝ հավելվածները պահելու համար (բոլոր տարբերակները, որոնք ես ներբեռնել եմ): Եթե ​​ես նման դրայվ միացնեմ, ինձ պետք է, որ հավելվածները գործարկվեն կրկնակի սեղմումով։ Haiku-ն պահպանում է փաթեթների հին տարբերակները, բայց ես չգիտեմ, թե ինչպես դրանք տեղափոխել արտաքին դրայվ, կամ ինչպես գործարկել հավելվածները հետագայում:

Մշակողի մեկնաբանությունը.

Տեխնիկապես դա արդեն հնարավոր է mount հրամանի միջոցով: Իհարկե, մենք դրա համար կստեղծենք GUI, հենց որ ունենանք բավականաչափ հետաքրքրված օգտվողներ:

• Ինձ պետք չեն միլիոնավոր ֆայլեր, որոնք սփռված են ֆայլային համակարգով, որոնք ես ինքս չեմ կարող ձեռքով կառավարել: Ես ուզում եմ մեկ ֆայլ մեկ հավելվածի համար, որը ես կարող եմ հեշտությամբ ներբեռնել, տեղափոխել, ջնջել: Haiku-ում այս խնդիրը լուծվում է փաթեթների միջոցով .hpkg, որոնք փոխանցում են, օրինակ, python-ը հազարավոր ֆայլերից մեկի մեջ։ Բայց եթե կա, օրինակ, python օգտագործող Scribus, ապա ես պետք է գործ ունենամ առնվազն երկու ֆայլի հետ։ Եվ ես պետք է հոգ տանեմ, որ պահպանեմ դրանց տարբերակները, որոնք աշխատում են միմյանց հետ:

Նույն Linux-ով կողք կողքի աշխատող AppImages-ի բազմաթիվ տարբերակներ

Հավելվածի մշակողի տեսակետը

Եկեք նայենք հավելվածի մշակողի տեսանկյունից.

• Ես ուզում եմ վերահսկել ամբողջ օգտագործողի փորձը: Ես չեմ ուզում կախված լինել օպերացիոն համակարգից, որպեսզի ինձ ասի, թե երբ և ինչպես պետք է թողարկեմ հավելվածները: Haiku-ն թույլ է տալիս ծրագրավորողներին աշխատել իրենց սեփական hpkg պահեստների հետ, սակայն դա նշանակում է, որ օգտատերերը պետք է ձեռքով կարգավորեն դրանք, ինչը գաղափարը դարձնում է «պակաս գրավիչ»:
• Ես ունեմ ներբեռնման էջ իմ կայքում, որտեղ ես տարածում եմ .exe Windows-ի համար, .dmg Mac-ի համար և .AppImage Linux-ի համար։ Կամ գուցե ես ուզում եմ դրամայնացնել մուտքը այս էջ, ամեն ինչ հնարավոր է: Ի՞նչ պետք է այնտեղ դնեմ Հայկուի համար: Ֆայլը բավական է .hpkg միայն HaikuPorts-ից կախվածություններով
• Իմ ծրագրաշարը պահանջում է այլ ծրագրերի հատուկ տարբերակներ: Օրինակ, հայտնի է, որ Krita-ն պահանջում է Qt-ի կարկատված տարբերակ, կամ Qt, որը մանրակրկիտ հարմարեցված է Krita-ի կոնկրետ տարբերակին, առնվազն մինչև patches-ը հետ մղվեն Qt-ի մեջ: Դուք կարող եք փաթեթավորել ձեր սեփական Qt-ը ձեր հավելվածի համար փաթեթում .hpkg, բայց ամենայն հավանականությամբ սա ողջունելի չէ։

Հավելվածի ներբեռնման կանոնավոր էջ: Ի՞նչ պետք է տեղադրեմ այստեղ Հայկուի համար:

Will փաթեթներ (որպես հավելվածների գրացուցակներ, ինչպիսիք են AppDir կամ .app Apple-ի ոճով) և/կամ պատկերներ (խիստ փոփոխված AppImages-ի տեսքով կամ .dmg Apple-ից) հավելվածները օգտակար հավելո՞ւմ են Haiku աշխատասեղանի միջավայրին: Թե՞ այն կթուլացնի ամբողջ պատկերը և կհանգեցնի մասնատման, հետևաբար կավելացնի բարդություն: Ես պատռված եմ. մի կողմից, Հայկուի գեղեցկությունն ու նրբագեղությունը հիմնված է այն բանի վրա, որ սովորաբար ինչ-որ բան անելու մեկ եղանակ կա, այլ ոչ թե շատ: Մյուս կողմից, կատալոգների և/կամ հավելվածների համար նախատեսված ենթակառուցվածքների մեծ մասն արդեն առկա է, ուստի համակարգը աղաղակում է, որ մնացած մի քանի տոկոսն իր տեղը զբաղեցնի:

Ըստ մշակողի պրն. թափթփել

Linux-ում նրանք (կատալոգներ և կիրառական փաթեթներ, - մոտ. թարգմանիչ) ամենայն հավանականությամբ համակարգային խնդիրների տեխնիկական լուծում են: Haiku-ում մենք նախընտրում ենք պարզապես լուծել համակարգային խնդիրները։

Ինչ ես կարծում?

Պատասխանելուց առաջ...

Սպասեք, եկեք իրականության արագ ստուգում կատարենք. իրականում դիմումների գրացուցակներ - արդեն Հայկուի մի մասն է.

Հավելվածի դիրեկտորիաներն արդեն գոյություն ունեն Haiku-ում, բայց դեռ չեն աջակցվում ֆայլերի կառավարիչում

Նրանք պարզապես այնքան լավ չեն աջակցվում, որքան, ասենք, Macintosh Finder-ը: Որքան լավ կլիներ, եթե QtCreator գրացուցակը վերևի ձախ անկյունում ունենար «QtCreator» անուն և պատկերակ, որը գործարկում էր հավելվածը, երբ կրկնակի սեղմում եք:

Մի քիչ ավելի վաղ ես արդեն հարցրեց:

Վստա՞հ եք, որ կարող եք գործարկել ձեր տասնամյակների վաղեմության հավելվածներն այսօր, երբ բոլոր հավելվածների խանութներն ու բաշխման պահոցները մոռացել են դրանց և դրանց կախվածության մասին: Վստա՞հ եք, որ ապագայում դեռ կկարողանաք մուտք գործել ձեր ընթացիկ աշխատանքը:

Արդեն կա՞ պատասխան Haiku-ից, թե՞ կատալոգներն ու հավելվածների փաթեթները կարող են օգնել այստեղ։ Կարծում եմ՝ կարող են։

Ըստ պրն. waddlesplash:

Այո, մենք ունենք հարցի պատասխանը. մենք պարզապես կաջակցենք այս հավելվածներին այնքան ժամանակ, որքան անհրաժեշտ է, մինչև ինչ-որ մեկը կարողանա ճիշտ կարդալ իրենց ֆայլերի ձևաչափերը կամ ապահովել մեկ առ մեկ ֆունկցիոնալություն: Haiku-ում BeOS R5 հավելվածներին աջակցելու մեր հանձնառությունը դրա ապացույցն է...

Սա հաստատ է:

Ինչ քայլեր պետք է ձեռնարկի Հայկուն:

Ես պատկերացնում եմ hpkg-ի, դիրեկտորիաների և հավելվածների պատկերների խաղաղ համակեցությունը.

• Համակարգային ծրագրաշարի օգտագործում .hpkg
• Ամենահաճախ օգտագործվող ծրագրերի համար (հատկապես նրանք, որոնք պետք է պլանավորեն շարժական թողարկումները), օգտագործեք .hpkg (բոլոր դեպքերի մոտ 80%-ը)
• Որոշները տեղադրված են միջոցով .hpkg, հավելվածները կշահեն հավելվածների գրացուցակի ենթակառուցվածք տեղափոխվելուց (օրինակ՝ QtCreator). դրանք կբաշխվեն որպես .hpkg, ինչպես նախկինում:

պրն. waddlesplash-ը գրում է.

Եթե ​​Ձեզ անհրաժեշտ է միայն հավելվածները դիտել /system/apps, փոխարենը մենք պետք է օգտատերերի համար ավելի կառավարելի դարձնենք Deskbar-ի դիրեկտորիաները, քանի որ /system/apps նախատեսված չէ օգտատերերի կողմից պարբերաբար բացվելու և դիտելու համար (ի տարբերություն MacOS-ի): Նման իրավիճակների համար Հայկուն այլ պարադիգմ ունի, սակայն այս տարբերակը, տեսականորեն, ընդունելի է։

• Haiku-ն ստանում է հավելվածի պատկերներ գործարկելու ենթակառուցվածք, ծրագրային ապահովման գիշերային, շարունակական և փորձնական կառուցումներ, ինչպես նաև այն դեպքերի համար, երբ օգտատերը ցանկանում է «սառեցնել այն ժամանակին», մասնավոր և ներքին ծրագրերի և այլ հատուկ օգտագործման դեպքերի համար (մոտ 20%): բոլորից): Այս պատկերները պարունակում են հավելվածը գործարկելու համար անհրաժեշտ ֆայլեր .hpkg, տեղադրվել է համակարգի կողմից, իսկ դիմումի ավարտից հետո՝ ապամոնտաժված։ (Հավանաբար ֆայլերի կառավարիչը կարող է տեղադրել ֆայլեր .hpkg հավելվածի պատկերների մեջ՝ ավտոմատ կերպով կամ օգտագործողի խնդրանքով, օրինակ, երբ հավելվածը քաշում եք ցանցային գրացուցակ կամ արտաքին սկավառակ: Դա ուղղակի երգ է։ Ավելի ճիշտ՝ պոեզիա՝ հայկու։) Մյուս կողմից՝ օգտագործողը կարող է ցանկանալ տեղադրել պատկերի բովանդակությունը ֆայլերի տեսքով։.hpkg, որից հետո դրանք կթարմացվեն ու կմշակվեն այնպես, ինչպես եթե տեղադրվեն HaikuDepot-ի միջոցով... Պետք է ուղեղի փոթորիկ անել):

Մեջբերում պրն. waddlesplash:

Արտաքին կրիչներից կամ ցանցային գրացուցակներից հավելվածների գործարկումը կարող է օգտակար լինել: Եվ pkgman-ի համար ավելի շատ «գոտիներ» կազմաձևելու հնարավորություն ավելացնելը, անկասկած, լավ հատկություն կլինի:

Նման համակարգը կօգտվի hpkg-ից, դիրեկտորիաներից և հավելվածի պատկերներից: Առանձին-առանձին լավ են, բայց միասին անպարտելի կդառնան։

Ամփոփում

Haiku-ն ունի շրջանակ, որն ապահովում է հասարակ և բարդ օգտատերերի փորձը համակարգչի համար և շատ ավելին է, քան սովորաբար տրամադրվում է Linux համակարգչի համար: Փաթեթային համակարգ .hpkg այդպիսի օրինակներից մեկն է, բայց համակարգի մնացած մասը նույնպես ներծծված է բարդությամբ: Այնուամենայնիվ, Հայկուն կշահի համապատասխան գրացուցակի և հավելվածի պատկերի աջակցությունից: Թե ինչպես դա անել լավագույնս, արժե քննարկել այն մարդկանց հետ, ովքեր գիտեն Հայկուն, նրա փիլիսոփայությունն ու ճարտարապետությունը շատ ավելի լավ, քան ես: Ի վերջո, ես օգտագործում եմ Հայկուն մեկ շաբաթից մի փոքր ավելի: Այնուամենայնիվ, ես հավատում եմ, որ Հայկուի դիզայներները, մշակողները և ճարտարապետները կշահեն այս թարմ հեռանկարից: Առնվազն, ես ուրախ կլինեմ լինել նրանց «սպարինգ գործընկերը»: Ես ավելի քան 10 տարվա գործնական փորձ ունեմ Linux հավելվածների կատալոգների և փաթեթների հետ, և ես կցանկանայի դրանց օգտագործումը գտնել Haiku-ում, ինչի համար, կարծում եմ, դրանք կատարյալ տեղավորվում են: Իմ առաջարկած պոտենցիալ լուծումները ոչ մի դեպքում միակ ճիշտ լուծումներն են իմ նկարագրած խնդիրների համար, և եթե Հայկու թիմը որոշի գտնել այլ, ավելի էլեգանտ լուծումներ, ես դրան կողմ եմ: Հիմնականում ես արդեն մտածում եմ համակարգ ստեղծելու գաղափարի մասին hpkg նույնիսկ ավելի զարմանալի, առանց փոխելու դրա աշխատանքի ձևը: Պարզվում է, որ Haiku թիմը երկար ժամանակ մտածում էր հավելվածների փաթեթների մասին փաթեթների կառավարման համակարգ ներդրելիս, բայց ցավոք (կարծում եմ) գաղափարը «հնացավ»։ Միգուցե ժամանակն է այն վերակենդանացնելու՞։

Փորձեք ինքներդ: Ի վերջո, Haiku նախագիծը տրամադրում է պատկերներ DVD-ից կամ USB-ից բեռնելու համար՝ ստեղծված օրական.
Հարցեր ունե՞ք։ Հրավիրում ենք ռուսախոս հեռագրային ալիք.

Սխալի ակնարկ. Ինչպես կրակել ձեր ոտքին C և C++-ով. Haiku OS բաղադրատոմսերի հավաքածու

- Ից հեղինակ թարգմանություն. սա Հայկուի մասին մատենաշարի ութերորդ և վերջին հոդվածն է։

Հոդվածների ցանկ. Առաջին Երկրորդ Երրորդը Չորրորդ Հինգերորդ վեցերորդ Յոթերորդ

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Արդյո՞ք իմաստ ունի hpkg համակարգը տեղափոխել Linux:

• Այո

• Ոչ

• Արդեն իրականացված է, կգրեմ մեկնաբանություններում

Քվեարկել է 20 օգտատեր։ 5 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com