Што-што яшчэ: пакеты прыкладанняў Haiku?

TL, д-р: ці можа Haiku атрымаць належную падтрымку пакетаў дадаткаў, да прыкладу каталогаў дадаткаў (як .app у Mac) і/або выяў прыкладанняў (Linux AppImage)? Мне здаецца, гэта будзе годным дадаткам, які правільна ўкараніць прасцей, чым у іншых сістэмах, паколькі большая частка інфраструктуры ўжо ёсць.

Тыдзень таму я адкрыў для сябе Haiku, нечакана добрую сістэму. Ну а паколькі я даўно цікаўлюся каталогамі і выявамі прыкладанняў (натхнёнымі прастатой Macintosh), то нядзіўна, што мне ў галаву прыйшла ідэя…

Для поўнага разумення: я стваральнік і аўтар AppImage, фармату распаўсюджвання прыкладанняў Linux, накіраванага на прастату Mac і які прадстаўляе поўнае кіраванне аўтарам прыкладанняў і канчатковым карыстачам (хочаце ведаць больш - гл. вікі и дакументацыю).

Што калі мы зробім AppImage для Haiku?

Давайце крыху, чыста тэарэтычна, паразважаем: што трэба зрабіць для таго, каб атрымаць AppImage, ці нешта падобнае, на Haiku? Неабавязкова ствараць нешта прама цяпер, бо сістэма, якая ўжо ёсць у Haiku, працуе дзіўна, а вось уяўны эксперымент атрымаўся б нядрэнны. А яшчэ ён дэманструе вытанчанасць Haiku, у параўнанні з працоўнымі асяроддзем Linux, дзе падобныя рэчы жудасна цяжкія (маю права так казаць: 10 гадоў ужо маюся з адладкай).

На Macintosh System 1 кожнае прыкладанне было асобным файлам, які кіруецца ў Finder. Выкарыстоўваючы AppImage я спрабую перастварыць гэты ж карыстацкі досвед на Linux.

Па-першае, а што такое AppImage? Гэта сістэма для выпуску прыкладанняў іншых распрацоўшчыкаў (напрыклад, Ultimaker Cure), якая дазваляе выпускаць прыкладанні, калі і як ім паляванне: не трэба ведаць асаблівасці розных дыстрыбутываў, палітык зборкі або інфраструктуры зборкі, не патрэбна падтрымка суправаджаюць, і яны не паказваюць карыстальнікам, што (не)можна ўсталёўваць у сябе на кампутарах. AppImage варта разумець як нешта, падобнае на пакет для Mac у фармаце .app ўнутры вобраза дыска .dmg. Асноўнае адрозненне ў тым, што прыкладанні не капіююцца, а застаюцца ўнутры AppImage заўсёды, прыкладна гэтак жа, як пакеты Haiku .hpkg мантуюцца, і ніколі не ўсталёўваюцца ў звычайным сэнсе.

AppImage за больш за 10 гадоў існавання атрымаў некаторую прыцягальнасць і папулярнасць: сам Лінус Торвальдс публічна ўхваліў яго, а распаўсюджаныя праекты (да прыкладу, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) прынялі яго ў якасці асноўнага спосабу распаўсюджвання бесперапынных ці начных зборак, не якія замінаюць усталяваным ці не ўсталяваным прыкладанням карыстачоў. Аднак працоўныя асяроддзі і дыстрыбутывы Linux часцей за ўсё па-ранейшаму чапляюцца за традыцыйную, цэнтралізаваную мадэль распаўсюджвання на аснове суправаджаючых і/ці прасоўваюць уласныя карпаратыўныя бізнэс і/ці інжынерныя праграмы на аснове Flatpak (RedHat, Fedora, GNOME) і Энергічны (Canonical, Ubuntu). Даходзіць да смешнага.

Як усё працуе

• Кожны AppImage змяшчае ў сабе 2 часткі: маленькі выкананы па падвойным пстрычцы ELF (т.зв. runtime.c), з наступным чынам файлавай сістэмы СквошFS.

• Файлавая сістэма SquashFS утрымоўвае карысную нагрузку ў выглядзе прыкладання і ўсяго неабходнага для яго запуску, якое ў разумным розуме нельга лічыць часткай усталёўкі па-змаўчанні для кожнай досыць свежай мэтавай сістэмы (дыстрыбутыва Linux). Таксама яна змяшчае метададзеныя, напрыклад імя прыкладання, абразкі, тыпы MIME і інш., інш.

• Пры запуску карыстачом runtime выкарыстае FUSE і squashfuse для мантавання файлавай сістэмы, пасля чаго апрацоўвае запуск некаторай кропкі ўваходу (т.зв. AppRun) усярэдзіне змантаванага AppImage.
  Файлавая сістэма размантуецца пасля таго, як завершыцца працэс.

Накшталт усё проста.

А гэтыя рэчы ўсё ўскладняюць:

• з такой разнастайнасцю дыстрыбутываў Linux ужо нішто "у разумным розуме" не назавеш "часткай усталёўкі па-змаўчанні для кожнай свежай мэтавай сістэмы". Мы абыходзім гэтую праблему шляхам зборкі excludelist, які дазваляе вызначыць, што будзе запакаваная ў 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.

Месцам захоўвання cross-desktop спецыфікацый, якія выкарыстоўваюцца ў GNOME, KDE и Xfce з'яўляецца freedesktop.org

Дасягненне ўзроўню вытанчанасці, глыбока ўплеценага ў працоўнае асяроддзе Haiku, абцяжарана, калі не сказаць "немагчыма", з-за спецыфікацый XDG ад freedesktop.org для cross-desktop, а таксама рэалізацый мэнэджэраў працоўнага стала на аснове гэтых спецыфікацый. У якасці прыкладу можна прывесці адзін агульнасістэмны абразок Firefox: мабыць, аўтарам XDG і ў галаву не прыйшло, што ў карыстача можа быць усталявана некалькі версій аднаго і таго ж прыкладанні.

Абразкі розных версій Firefox

Мне было цікава, чаму мір Linux мог бы навучыцца ў Mac OS X, каб не лажаць пры сістэмнай інтэграцыі. Калі ў вас ёсць час і вы займаецеся такім - абавязкова пачытайце, што сказаў Арно Гурдол, адзін з першых інжынераў Mac OS X:

Мы хацелі, каб усталяваць прыкладанне было гэтак жа проста, як перацягнуць абразок прыкладання адкуль-небудзь (сервер, знешні дыск) на дыск вашага кампутара. Для гэтага ў пакеце прыкладання захавана ўся інфармацыя, уключаючы абразкі, версію, апрацоўваны тып файла, тып схем URL, якую сістэма павінна шляхта для апрацоўкі прыкладання. Сюды ж адносіцца інфармацыя для "цэнтралізаванага захоўвання" ў базе дадзеных Icon Services і Launch Services. Для падтрымкі прадукцыйнасці прыкладання 'выяўляюцца' у некалькіх 'добра вядомых' месцах: у сістэмным і карыстацкім каталогу Applications, а таксама ў некаторых іншых аўтаматычна, калі карыстач перайшоў у Finder у каталог, які змяшчае прыкладанне. На практыцы гэта вельмі добрае спрацавала.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 сесія 144 - Mac OS X: упакоўка прыкладанняў і раздрукоўка дакументаў.

Нічога падобнага з гэтай інфраструктуры няма на працоўных асяродках Linux, таму мы шукаем абыходныя шляхі вакол структурных абмежаванняў у праекце AppImage.

Няўжо Haiku спяшаецца на дапамогу?

І яшчэ: платформы Linux у якасці асновы працоўных асяроддзяў, як правіла, да таго недаспецыфікаваны, што шматлікія рэчы, якія вельмі простыя ва ўзгодненай сістэме з поўным стэкам, расчароўваюць фрагментаванасцю і складанасцю ў Linux. Я прысвяціў цэлы даклад пытанням, звязаным з платформай Linux для працоўных акружэнняў (дасведчаныя распрацоўшчыкі пацвердзілі: усё так і застанецца яшчэ вельмі надоўга).

Мой даклад па праблемах працоўных асяродкаў Linux у 2018

Нават Лінус Торвальдс прызнаў, што менавіта з-за фрагментацыі ідэя працоўных акружэнняў не ўдалася.

Прыемна бачыць Haiku!

З Haiku усё становіцца надзвычай простым

Хоць наіўны падыход да "пераносу" AppImage на Haiku заключаецца ў простай спробе зборкі (у асноўным runtime.c і сэрвісу) яго кампанентаў (што можа быць нават і магчыма!), гэта не прынясе асаблівай карысці для Haiku. Таму што насамрэч большасць гэтых праблем вырашана на Haiku і канцэптуальна абгрунтавана. Haiku падае менавіта тыя цаглінкі для сістэмнай інфраструктуры, якія я так доўга шукаў у працоўных асяродках на Linux і не мог паверыць, што іх тамака няма. А менавіта:

Ці верыце ці не, але гэта не могуць перамагчы шматлікія карыстачы Linux. На Haiku усё робіцца аўтамагічна!

• Файлы ELF, не мелыя біта выканальнасці, атрымлівае яго аўтаматычна пры падвойнай пстрычцы ў файлавым мэнэджары.
• Прыкладанні могуць мець убудаваныя рэсурсы, да прыкладу абразкі, якія адлюстроўваюцца ў файлавым мэнэджары. Не трэба капіяваць кучу малюнкаў у адмысловыя каталогі з абразкамі, а такім чынам, не трэба іх падчышчаць пасля выдалення ці перасоўванні прыкладання.
• Ёсць база дадзеных для звязвання прыкладанняў з дакументамі, няма неабходнасці капіяваць якія-небудзь файлы для гэтага.
• У каталогу lib/ побач з выкананым файлам бібліятэкі шукаюцца па змаўчанні.
• Няма шматлікіх дыстрыбутываў і асяродкаў працоўнага стала, усё што працуе - працуе ўсюды.
• Не існуе асобнага модуля для запуску, які адрозніваўся б ад каталога Applications.
• У дадатках няма ўбудаваных абсалютных шляхоў да сваіх рэсурсаў, ёсць спецыяльныя функцыі для вызначэння месцазнаходжання падчас выканання.
• Укаранёна ідэя сціснутых выяў файлавых сістэм: гэта любы пакет hpkg. Усе яны мантуюцца ядром.
• Кожны файл адчыняецца дадаткам, якое яго стварыла, калі відавочна не паказаць нешта іншае. Як жа гэта крута!

Два файлы png. Звярніце ўвагу на розныя абразкі, якія паказваюць, што яны будуць адкрывацца рознымі праграмамі па падвойнай пстрычцы. Таксама звернеце ўвагу на выпадальнае меню «Адкрыць з дапамогай:», дзе карыстач можа абраць асобнае прыкладанне. Як проста!

Выглядае так, што шматлікія мыліцы і абыходныя шляхі, патрэбныя AppImage на Linux, становяцца непатрэбнымі на Haiku, мелую ў сваёй аснове прастату і вытанчанасць, дзякуючы якім яна спраўляецца з большасцю нашых патрэб.

Ці патрэбныя Haiku пакеты прыкладанняў, у рэшце рэшт?

Гэта падводзіць да вялікага пытання. Калі б на Haiku стварыць сістэму накшталт AppImage аказалася на парадак прасцей, чым на Linux, варта было б гэтым заняцца? Ці ж Haiku з яе сістэмай пакетаў hpkg фактычна ўхіліла неабходнасць распрацоўкі падобнай ідэі? Што ж, для адказу трэба зірнуць на матывацыю існавання AppImages.

Погляд з боку карыстальніка

Паглядзім на нашага канчатковага карыстальніка:

• Я хачу паставіць дадатак без запыту пароля адміністратара (root). На Haiku няма паняцця адміністратара, у карыстача поўны кантроль, паколькі гэта персанальная сістэма! (У прынцыпе, можна ўявіць гэта і ў шматкарыстальніцкім рэжыме, спадзяюся, распрацоўшчыкі захаваюць прастату)
• Я хачу атрымліваць апошнія і лепшыя версіі прыкладанняў, не чакаць, калі яны з'явяцца ў маім дыстрыбутыве (часцей за ўсё гэта значыць "ніколі", прынамсі, калі не абнавіць усю аперацыёнку). На Haiku гэта "вырашана" з дапамогай плаваюць выпускаў. Гэта азначае, што ёсць магчымасць атрымліваць апошнія і лепшыя версіі прыкладанняў, але для гэтага трэба ўвесь час абнаўляць і астатнюю частку сістэмы, фактычна ператвараючы яе ў «якая рухаецца мэта».
• Мне жадаецца некалькі версій аднаго і таго ж прыкладанні побач, паколькі нельга пазнаць, што было зламанае ў апошняй версіі, ці, дапусцім, мне, як вэб-распрацоўніку, трэба праверыць сваю працу пад рознымі версіямі браўзэра. У Haiku вырашана першая, але не другая праблема. Абнаўленні адкочваюцца, але толькі для сістэмы цалкам, немагчыма (як мне вядома) запусціць, да прыкладу, некалькі версій WebPositive ці LibreOffice адначасова.

Адзін з распрацоўшчыкаў піша:

Па сутнасці, абгрунтаванне такое: сцэнар выкарыстання настолькі рэдкі, што аптымізацыя для яго не мае сэнсу; апрацоўка яго, як асаблівага выпадку, у HaikuPorts, здаецца больш чым прымальнай.

• Мне трэба захоўваць прыкладанні там, дзе мне падабаецца, а не на загрузнай кружэлцы. На дысках у мяне часта заканчваецца месца, так што мне трэба падключаць вонкавы дыск або сеткавы каталог для захоўвання прыкладанняў (усіх версій, што я запампаваў). Калі я падлучаю такі дыск - трэба каб прыкладанні запускаліся па падвойнай пстрычцы. Haiku захоўвае старыя версіі пакетаў, але я не ведаю як перамясціць іх на знешні дыск, а таксама як потым выклікаць прыкладанні адтуль.

Каментар распрацоўніка:

Тэхнічна, гэта ўжо магчыма з камандай mount. Вядома, мы зробім GUI для гэтага, як толькі набярэцца дастаткова зацікаўленых карыстальнікаў.

• Мне не патрэбныя мільёны файлаў, якія былі раскіданыя па файлавай сістэме, якімі я не магу самастойна ўручную кіраваць. Хачу адзін файл на дадатак, які я магу лёгка спампаваць, перамясціць, выдаліць. На Haiku гэтая праблема вырашана з дапамогай пакетаў. .hpkg, якія пераносяць, да прыкладу python, з тысяч файлаў у адзін. Але калі ёсць, да прыкладу, Scribus, які выкарыстоўвае python, то мне даводзіцца мець справу мінімум з двума файламі. І я павінен паклапаціцца аб тым, каб захаваць іх версіі, якія працуюць адзін з адным.

Шматлікія версіі AppImages, запушчаны побач на адным Linux

Погляд з боку распрацоўшчыка прыкладанняў

Давайце паглядзім з пункту гледжання распрацоўшчыка прыкладанняў:

• Я жадаю кіраваць карыстацкім досведам цалкам. Не хачу залежаць ад аперацыйнай сістэмы, якая будзе мне ўказваць, калі і як я павінен выпускаць прыкладанні. У Haiku распрацоўнікам можна працаваць са сваімі ўласнымі рэпазітарамі hpkg, але гэта азначае, што карыстачам трэба будзе наладжваць іх уручную, што робіць гэтую ідэю "менш прывабнай".
• У мяне ёсць старонка загрузкі на маім вэб-сайце, дзе я распаўсюджваю .exe для Windows, .dmg для Mac і .AppImage для Linux. А можа, я захачу манетызаваць доступ да гэтай старонкі, усё можа быць? Што мне трэба размясціць там для Haiku? Дастаткова файла .hpkg з залежнасцямі толькі ад HaikuPorts
• Майму ПЗ патрэбныя пэўныя версіі іншага ПЗ. Да прыкладу, вядома, што для Krita патрэбна выпраўленая версія Qt, ці Qt, якая сапраўды наладжана на пэўную версію Krita, прынамсі, датуль, пакуль выпраўленні не вернуцца зваротна ў Qt. Можна спакаваць уласны Qt для прыкладання ў пакеце .hpkg, Але хутчэй за ўсё, такое не вітаецца.

Звычайная старонка загрузкі прыкладання. Што ж размясціць тут для Haiku?

Ці стануць камплекты (існуючыя ў выглядзе каталогаў прыкладанняў, як AppDir або .app у стылі Apple) і/ці выявы (у выглядзе моцна мадыфікаваных AppImages або .dmg ад Apple) прыкладанняў карысным дадаткам для працоўнага асяроддзя Haiku? Ці гэта разбавіць цэласную карціну і прывядзе да фрагментацыі, а такім чынам, дадасць складанасці? Я раздзіраюся: з аднаго боку, прыгажосць і вытанчанасць Haiku заснаваныя на тым, што звычайна ёсць адзін спосаб зрабіць нешта, а не шмат. З іншага боку, большая частка інфраструктуры для каталогаў і/ці камплектаў прыкладанняў ужо на месцы, таму сістэма заклікае да таго, каб на свае месцы ўсталі і пакінутыя некалькі адсоткаў.

Паводле распрацоўніка mr. waddlesplash

На Linux яны (каталогі і камплекты прыкладанняў, - заўв. перакладчыка) хутчэй за ўсё з'яўляюцца тэхнічным рашэннем сістэмных праблем. На Haiku мы аддаем перавагу проста вырашаць сістэмныя праблемы.

А што вы думаеце?

Перш чым адкажаце…

Пачакайце, зробім хуткую праверку на рэальнасць: па факце каталогі прыкладанняў - ужо частка Haiku:

Каталогі прыкладанняў ужо існуюць на Haiku, але пакуль не падтрымліваюцца ў файлавым мэнэджэры

Яны проста не так добра падтрымліваюцца, як, скажам, у Macintosh Finder. Наколькі было б крута, калі б каталог QtCreator меў бы ў верхнім левым куце імя і абразок «QtCreator», якія запускаюць прыкладанне па падвойнай пстрычцы?

Крыху раней я ўжо пытаўся:

Вы ўпэўненыя, што запусціце свае прыкладанні дзесяцігадовай даўніны сёння, калі ўсе крамы прыкладанняў і рэпазітары дыстрыбутываў забудуцца пра іх і іх залежнасці? Вы ўпэўнены, што па-ранейшаму зможаце атрымаць доступ да сваёй цяперашняй працы ў будучыні?

Ці ёсць ужо адказ з боку Haiku, ці каталогі і камплекты дадаткаў змогуць тут дапамагчы? Я думаю, здолеюць.

Згодна з mr. waddlesplash:

Так, у нас ёсць адказ на пытанне: мы проста будзем падтрымліваць гэтыя прыкладанні столькі, колькі трэба, пакуль хто-небудзь не зможа правільным спосабам прачытаць іх фарматы файлаў або забяспечыць функцыянальнасць адзін да аднаго. Наша імкненне падтрымліваць працу прыкладанняў BeOS R5 на Haiku – прамое таму доказ…

Гэта дакладна!

Які план дзеянняў павінна прыняць Haiku?

Я магу ўявіць мірнае суіснаванне hpkg, каталогаў і вобразаў прыкладанняў:

• Сістэмнае ПЗ выкарыстоўвае .hpkg
• Для найболей часта выкарыстоўванага ПЗ (асабліва для таго, якому трэба запланаваць плывучыя выпускі) выкарыстоўваецца .hpkg (прыкладна 80% усіх выпадкаў)
• Некаторыя, устаноўленыя праз .hpkg, прыкладанні выйграюць пры пераходзе на інфраструктуру з каталогамі прыкладанняў (да прыкладу, QtCreator): яны будуць распаўсюджвацца ў выглядзе .hpkg, Як і раней.

mr. waddlesplash піша:

Калі ўсё, што трэба, гэта - прагляд прыкладанняў у /system/apps, замест гэтага трэба зрабіць каталогі ў Deskbar больш кіраванымі для карыстачоў, паколькі /system/apps не прызначаны для таго, каб карыстачы рэгулярна адчынялі і глядзелі яго (у адрозненне ад MacOS). Для такіх сітуацый у Haiku іншая парадыгма, але гэты варыянт, па ідэі, прымальны.

• Haiku атрымлівае інфраструктуру для запуску выяў прыкладанняў, начных, бесперапынных і тэставых зборак ПА, а таксама на выпадкі, калі карыстач жадае яго "замарозіць у часе", для прыватнага і ўнутранага ПА, і іншых асаблівых выпадкаў выкарыстання (каля 20% ад усіх). Гэтыя выявы ўтрымоўваюць неабходныя для запуску прыкладання файлы .hpkg, якія мантуюцца сродкамі сістэмы, а пасля завяршэння прыкладання - размантаваныя. (Магчыма, файлавы менеджэр мог бы змяшчаць файлы .hpkg у выявы прыкладанняў, аўтаматычна ці па патрабаванні карыстача — ну, як калі перацягваеш прыкладанне на сеткавы каталог ці вонкавы дыск. Гэта ж проста песня! А дакладней паэзія - хайку.) З іншага боку, карыстач можа захацець усталяваць змесціва выявы ў выглядзе файлаў.hpkg, пасля чаго яны будуць абнаўляцца і апрацоўвацца сапраўды таксама, як калі б былі ўсталяваныя праз HaikuDepot… Трэба правесці мазгавы штурм).

Цытата ад mr. waddlesplash:

Запуск прыкладанняў з вонкавых дыскаў або сеткавых каталогаў патэнцыйна можа быць карысным. А даданне магчымасці налады большай колькасці "зон" для pkgman вызначана стане добрай функцыяй.

Падобная сістэма будзе выкарыстоўваць перавагі hpkg, каталогаў і вобразаў прыкладанняў. Яны добрыя і паасобку, але разам стануць непераможнымі.

Заключэнне

Для Haiku ёсць інфраструктура, якая прадстаўляе просты і вытанчаны карыстацкі інтэрфейс для ПК, і далёка выходзіць за рамкі таго, што звычайна падаецца для ПК на Linux. Сістэма пакетаў .hpkg - Адзін з такіх прыкладаў, але астатнія часткі сістэмы таксама прасякнуты вытанчанасцю. Тым не менш, ад правільнай падтрымкі каталогаў і вобразаў прыкладанняў Haiku б выйграла. Як гэта лепш за ўсё зрабіць - варта абмеркаваць з людзьмі, якія ведаюць Haiku, яе філасофію і архітэктуру нашмат лепш, чым я. У рэшце рэшт я карыстаюся Haiku крыху больш за тыдзень. Але тым не менш, я лічу, што гэты свежы погляд апынецца карысны дызайнерам, распрацоўшчыкам і архітэктарам Haiku. Прынамсі, я з радасцю пабуду для іх "спарынг-партнёрам". У мяне больш за 10 гадоў практычнага досведу працы з каталогамі і камплектамі прыкладанняў для Linux, і мне хацелася б знайсці ім ужыванне для Haiku, для канцэпцыі якой, на маю думку, яны падыходзяць ідэальна. Прапанаваныя мною патэнцыйныя рашэнні зусім не з'яўляюцца адзіна дакладнымі для праблем, якія я апісаў, і калі каманда Haiku вырашыць знайсці іншыя, больш хупавыя, - я толькі ўсімі рукамі за. У прынцыпе, я ўжо абдумваю ідэю таго, як зрабіць сістэму hpkg яшчэ больш дзіўнай, не мяняючы спосабу яе працы. Апыняецца, каманда Haiku даўно думала аб камплектах прыкладанняў пры ўкараненні сістэмы кіравання пакетамі, але нажаль, (мне здаецца) ідэя сышла ў састарэлыя . Можа, прыйшоў час адрадзіць яе?

Паспрабуйце самі! Бо праект Haiku падае выявы для загрузкі з DVD ці USB, фармаваныя штодня.
Зьявіліся пытаньні? Запрашаем вас у рускамоўны telegram-канал.

Агляд памылак: Як стрэліць сабе ў нагу ў C і C ++. Зборнік рэцэптаў Haiku OS

Ад аўтара перакладу: гэта восьмы і заключны артыкул з цыклу пра Haiku.

Спіс артыкулаў: Першая Другая трэцяя чацвёртая пятая шостая Сёмая

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці ёсць сэнс партаваць сістэму hpkg для Linux?

• Так

• Няма

• Ужо рэалізавана, напішу ў каментарах

Прагаласавалі 20 карыстальнікаў. Устрымаліся 5 карыстальнікаў.

Крыніца: habr.com