Iba pa: Haiku app bundle?

Tl; DR: Maaari bang makakuha ng tamang suporta ang Haiku para sa mga pakete ng aplikasyon, gaya ng mga direktoryo ng aplikasyon (tulad ng .app sa Mac) at/o mga larawan ng application (Linux AppImage)? Sa tingin ko ito ay isang karapat-dapat na karagdagan na mas madaling ipatupad nang tama kaysa sa iba pang mga sistema dahil karamihan sa mga imprastraktura ay nasa lugar na.

Isang linggo na ang nakalipas Natuklasan ko ang Haiku, isang hindi inaasahang magandang sistema. Buweno, dahil matagal na akong interesado sa mga direktoryo at mga imahe ng application (na inspirasyon ng pagiging simple ng Macintosh), hindi nakakagulat na isang ideya ang pumasok sa aking isipan...

Para sa ganap na pag-unawa, ako ang lumikha at may-akda ng AppImage, isang format ng pamamahagi ng application ng Linux na naglalayon para sa pagiging simple ng Mac at nagbibigay ng ganap na kontrol sa mga may-akda ng application at mga end user (kung gusto mong malaman ang higit pa, tingnan ang wiki и dokumentasyon).

Paano kung gumawa tayo ng AppImage para sa Haiku?

Mag-isip tayo ng kaunti, puro theoretically: kung ano ang kailangang gawin upang makuha AppImage, o katulad nito, sa Haiku? Hindi kinakailangang lumikha ng isang bagay sa ngayon, dahil ang sistemang umiiral na sa Haiku ay gumagana nang kamangha-mangha, ngunit ang isang haka-haka na eksperimento ay magiging maganda. Ipinapakita rin nito ang pagiging sopistikado ng Haiku, kumpara sa mga Linux desktop environment, kung saan ang mga bagay na ito ay napakahirap (may karapatan akong sabihin ito: Nahihirapan ako sa pag-debug sa loob ng 10 taon).

Sa Macintosh System 1, ang bawat application ay isang hiwalay na file na "pinamamahalaan" sa Finder. Gamit ang AppImage Sinusubukan kong muling likhain ang parehong karanasan ng user sa Linux.

Una, ano ang isang AppImage? Ito ay isang sistema para sa pagpapalabas ng mga third-party na application (halimbawa, Ultimaker Cure), na nagpapahintulot sa mga application na ilabas kung kailan at kung paano nila gusto: hindi na kailangang malaman ang mga detalye ng iba't ibang mga pamamahagi, bumuo ng mga patakaran o bumuo ng imprastraktura, walang suporta sa maintainer ang kailangan, at hindi nila sinasabi sa mga user kung ano (hindi) ang maaari nilang i-install sa kanilang mga computer. Dapat na maunawaan ang AppImage bilang isang bagay na katulad ng isang pakete ng Mac sa format .app sa loob ng imahe ng disk .dmg. Ang pangunahing pagkakaiba ay ang mga application ay hindi kinokopya, ngunit mananatili sa loob ng AppImage magpakailanman, halos kapareho ng mga pakete ng Haiku .hpkg naka-mount, at hindi kailanman naka-install sa karaniwang kahulugan.

Sa paglipas ng higit sa 10 taon ng pag-iral, ang AppImage ay nakakuha ng ilang apela at katanyagan: si Linus Torvalds mismo ang nag-endorso nito sa publiko, at ang mga karaniwang proyekto (halimbawa, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ay pinagtibay ito bilang pangunahing paraan upang ipamahagi ang tuloy-tuloy o gabi-gabi na mga build, hindi nakakasagabal sa mga naka-install o na-uninstall na application ng user. Gayunpaman, ang Linux desktop environment at mga distribusyon ay kadalasang kumakapit pa rin sa tradisyonal, sentralisadong maintainer-based na modelo ng pamamahagi at/o nagpo-promote ng kanilang sariling negosyo sa negosyo at/o mga programa sa engineering batay sa Flatpak (RedHat, Fedora, GNOME) at Malinaw (Canonical, Ubuntu). Dumating ito katawa-tawa.

Paano gumagana ang lahat

• Ang bawat AppImage ay naglalaman ng 2 bahagi: isang maliit na double-click na ELF (tinatawag na. runtime.c), na sinusundan ng isang imahe ng file system SquashFS.

• Ang SquashFS file system ay naglalaman ng payload ng application at lahat ng kailangan para patakbuhin ito, na sa tamang pag-iisip ay hindi maituturing na bahagi ng default na pag-install para sa bawat medyo kamakailang target na sistema (pamamahagi ng Linux). Naglalaman din ito ng metadata, tulad ng pangalan ng application, mga icon, mga uri ng MIME, atbp., atbp.

• Kapag pinapatakbo ng user, gumagamit ang runtime ng FUSE at squashfuse upang i-mount ang filesystem, at pagkatapos ay humahawak sa pagpapatakbo ng ilang entry point (aka AppRun) sa loob ng naka-mount na AppImage.
  Ang file system ay na-unmount pagkatapos makumpleto ang proseso.

Parang simple lang ang lahat.

At ang mga bagay na ito ay nagpapagulo sa lahat:

• Sa ganoong iba't ibang mga distribusyon ng Linux, walang "sa tamang pag-iisip" ang matatawag na "bahagi ng default na pag-install para sa bawat bagong target na sistema." Inaayos namin ang isyung ito sa pamamagitan ng pagtatayo excludelist, na nagbibigay-daan sa iyong matukoy kung ano ang ipapakete sa AppImage at kung ano ang kailangang dalhin sa ibang lugar. Kasabay nito, kung minsan ay nakakaligtaan natin, sa kabila ng katotohanan na, sa pangkalahatan, lahat ay gumagana nang mahusay. Dahil dito, inirerekomenda namin na subukan ng mga tagalikha ng package ang AppImages sa lahat ng target na system (mga pamamahagi).
• Ang mga payload ng aplikasyon ay dapat na mailipat sa buong file system. Sa kasamaang palad, maraming mga application ang may hard-coded absolute paths papunta, halimbawa, mga mapagkukunan sa /usr/share. Kailangang ayusin ito kahit papaano. Bilang karagdagan, dapat kang mag-export LD_LIBRARY_PATH, o ayusin rpath para mahanap ng loader ang mga nauugnay na library. Ang unang paraan ay may mga kakulangan nito (na nagtagumpay sa mga kumplikadong paraan), at ang pangalawa ay simpleng masalimuot.
• Ang pinakamalaking UX pitfall para sa mga user ay iyon itakda ang executable bit AppImage file pagkatapos mag-download. Maniwala ka man o hindi, ito ay isang tunay na hadlang para sa ilan. Ang pangangailangan na itakda ang executability bit ay mahirap kahit para sa mga may karanasang user. Bilang isang solusyon, iminungkahi namin ang pag-install ng isang maliit na serbisyo na sumusubaybay sa mga file ng AppImage at nagtatakda ng kanilang executability bit. Sa dalisay nitong anyo, hindi ito ang pinakamahusay na solusyon, dahil hindi ito gagana sa labas ng kahon. Ang mga pamamahagi ng Linux ay hindi nagbibigay ng serbisyong ito, samakatuwid, ang mga gumagamit ay may masamang karanasan sa labas ng kahon.
• Inaasahan ng mga user ng Linux na ang isang bagong application ay magkakaroon ng icon sa startup menu. Hindi mo masasabi sa system: "Tingnan mo, may bagong application, magtrabaho tayo." Sa halip, ayon sa detalye ng XDG, kailangan mong kopyahin ang file .desktop sa tamang lugar sa /usr para sa isang buong system na pag-install, o sa $HOME para sa indibidwal. Ang mga icon ng ilang partikular na laki, ayon sa detalye ng XDG, ay kailangang ilagay sa ilang partikular na lugar sa usr o $HOME, at pagkatapos ay magpatakbo ng mga utos sa working environment para i-update ang icon cache, o umaasa na ang working environment manager ay malalaman ito at awtomatikong makita ang lahat. Pareho sa mga uri ng MIME. Bilang isang workaround, iminungkahi na gamitin ang parehong serbisyo, na, bilang karagdagan sa pagtatakda ng executability flag, ay, kung mayroong mga icon, atbp. sa AppImage, kopyahin ang mga ito mula sa AppImage papunta sa mga tamang lugar ayon sa XDG. Kapag tinanggal o inilipat, ang serbisyo ay inaasahang i-clear ang lahat. Siyempre, may mga pagkakaiba sa pag-uugali ng bawat kapaligiran sa pagtatrabaho, sa mga format ng graphic na file, ang kanilang mga laki, lokasyon ng imbakan at mga pamamaraan para sa pag-update ng mga cache, na lumilikha ng problema. Sa madaling salita, ang pamamaraang ito ay isang saklay.
• Kung hindi sapat ang nasa itaas, wala pa ring icon ng AppImage sa file manager. Ang mundo ng Linux ay hindi pa nagpasya na ipatupad ang elficon (sa kabila ng talakayan и pagpapatupad), kaya imposibleng i-embed ang icon nang direkta sa application. Kaya lumalabas na ang mga application sa file manager ay walang sariling mga icon (walang pagkakaiba, AppImage o iba pa), ang mga ito ay nasa start menu lamang. Bilang isang solusyon, gumagamit kami ng mga thumbnail, isang mekanismo na orihinal na idinisenyo upang payagan ang mga desktop manager na magpakita ng mga larawan ng preview ng thumbnail ng mga graphic na file bilang kanilang mga icon. Dahil dito, ang serbisyo para sa pagtatakda ng executability bit ay gumagana rin bilang isang "miniaturizer", paggawa at pagsulat ng mga thumbnail ng icon sa naaangkop na mga lokasyon /usr и $HOME. Ang serbisyong ito ay nagsasagawa rin ng paglilinis kung ang AppImage ay tinanggal o inilipat. Dahil sa ang katunayan na ang bawat desktop manager ay bahagyang naiiba, halimbawa, sa kung anong mga format ang tumatanggap ng mga icon, sa kung anong laki o lugar, lahat ito ay talagang masakit.
• Nag-crash lang ang application sa pagpapatupad kung may mga error na nangyari (halimbawa, mayroong library na hindi bahagi ng base system at hindi ibinibigay sa AppImage), at walang nagsasabi sa user sa GUI kung ano ang eksaktong nangyayari. Sinimulan naming libutin ito sa pamamagitan ng paggamit mga abiso sa desktop, na nangangahulugang kailangan nating mahuli ang mga error mula sa command line, i-convert ang mga ito sa mga mensaheng naiintindihan ng user, na pagkatapos ay kailangang ipakita sa desktop. At siyempre, ang bawat desktop environment ay humahawak sa kanila nang medyo naiiba.
• Sa ngayon (Setyembre 2019 - tala ng tagasalin) Wala akong nakitang simpleng paraan para sabihin sa system na ang file 1.png dapat buksan gamit ang Krita, at 2.png - gamit ang GIMP.

Lokasyon ng storage para sa mga cross-desktop na pagtutukoy na ginamit sa GNOME, kDE и Xfce ay freedesktop.org

Ang pagkamit ng antas ng pagiging sopistikado na malalim na hinabi sa kapaligiran ng trabaho ng Haiku ay mahirap, kung hindi imposible, dahil sa mga detalye XDG mula sa freedesktop.org para sa cross-desktop, pati na rin ang mga pagpapatupad ng mga desktop manager batay sa mga detalyeng ito. Bilang halimbawa, maaari naming banggitin ang isang icon ng Firefox sa buong system: tila, hindi man lang naisip ng mga may-akda ng XDG na maaaring magkaroon ng ilang bersyon ng parehong application na naka-install ang isang user.

Mga icon para sa iba't ibang bersyon ng Firefox

Nagtataka ako kung ano ang matututuhan ng mundo ng Linux mula sa Mac OS X upang maiwasang sirain ang pagsasama ng system. Kung mayroon kang oras at gusto mo ito, siguraduhing basahin ang sinabi ni Arnaud Gurdol, isa sa mga unang inhinyero ng Mac OS X:

Nais naming gawing kasingdali ng pag-drag sa icon ng application ang pag-install ng application mula sa kung saan (server, external drive) papunta sa iyong computer drive. Upang gawin ito, iniimbak ng package ng application ang lahat ng impormasyon, kabilang ang mga icon, bersyon, uri ng file na pinoproseso, uri ng mga scheme ng URL na kailangang malaman ng system upang maproseso ang application. Kasama rin dito ang impormasyon para sa 'central storage' sa Icon Services at Launch Services database. Upang suportahan ang pagganap, ang mga application ay 'nadiskubre' sa ilang mga 'kilalang' lugar: ang system at mga direktoryo ng Application ng user, at ilang iba pa ay awtomatiko kung magna-navigate ang user sa Finder sa direktoryo na naglalaman ng application. Sa pagsasagawa, ito ay nagtrabaho nang mahusay.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 session 144 - Mac OS X: packaging application at mga dokumento sa pag-print.

Walang katulad ang imprastraktura na ito sa mga desktop ng Linux, kaya naghahanap kami ng mga solusyon sa paligid ng mga limitasyon sa istruktura sa proyekto ng AppImage.

Ililigtas ba ni Haiku?

At isa pang bagay: Ang mga platform ng Linux bilang batayan ng mga desktop environment ay malamang na hindi masyadong tinukoy na maraming mga bagay na medyo simple sa isang pare-parehong full-stack system ay nakakabigo na pira-piraso at kumplikado sa Linux. Inilaan ko ang isang buong ulat sa mga isyung nauugnay sa platform ng Linux para sa mga desktop environment (nakumpirma ng mga maalam na developer na ang lahat ay mananatiling ganito sa napakatagal na panahon).

Ang aking ulat sa mga problema ng Linux desktop environment noong 2018

Kahit na si Linus Torvalds ay inamin na ang fragmentation ang dahilan kung bakit nabigo ang ideya sa workspace.

Masaya akong makita si Haiku!

Ginagawa ng Haiku na napakasimple ng lahat

Bagama't ang walang muwang na diskarte sa "pag-port" ng AppImage sa Haiku ay subukan lang na buuin (pangunahin ang runtime.c at serbisyo) ng mga bahagi nito (na maaaring maging posible!), hindi ito magbibigay ng malaking benepisyo sa Haiku. Sapagkat sa katunayan, karamihan sa mga problemang ito ay nalutas sa Haiku at may katumpakan sa konsepto. Eksaktong ibinibigay ng Haiku ang mga bloke ng pagbuo ng imprastraktura ng system na matagal ko nang hinahanap sa mga desktop environment ng Linux at hindi ako makapaniwalang wala doon. Namely:

Maniwala ka man o hindi, ito ay isang bagay na hindi kayang pagtagumpayan ng maraming gumagamit ng Linux. Sa Haiku, awtomatikong ginagawa ang lahat!

• Ang mga ELF file na walang executability bit ay awtomatikong makakakuha ng isa kapag na-double click sa file manager.
• Ang mga application ay maaaring magkaroon ng mga built-in na mapagkukunan, tulad ng mga icon, na ipinapakita sa file manager. Hindi na kailangang kopyahin ang isang grupo ng mga imahe sa mga espesyal na direktoryo na may mga icon, at samakatuwid ay hindi na kailangang linisin ang mga ito pagkatapos tanggalin o ilipat ang application.
• Mayroong isang database para sa pag-link ng mga application sa mga dokumento, hindi na kailangang kopyahin ang anumang mga file para dito.
• Sa lib/ directory sa tabi ng executable file, ang mga library ay hinahanap bilang default.
• Walang maraming distribusyon at desktop environment; anuman ang gumagana, gumagana sa lahat ng dako.
• Walang hiwalay na module na tatakbo na iba sa direktoryo ng Applications.
• Ang mga application ay walang mga built-in na absolute path sa kanilang mga mapagkukunan; mayroon silang mga espesyal na function para sa pagtukoy ng lokasyon sa runtime.
• Ang ideya ng mga naka-compress na file system na imahe ay ipinakilala: ito ay anumang hpkg package. Ang lahat ng mga ito ay naka-mount sa pamamagitan ng kernel.
• Ang bawat file ay binubuksan ng application na lumikha nito, maliban kung tahasan mong tinukoy kung hindi man. Astig ito!

Dalawang png file. Pansinin ang iba't ibang mga icon na nagsasaad na bubuksan sila ng iba't ibang mga application kapag na-double click. Tandaan din ang drop-down na menu na "Buksan gamit ang:" kung saan makakapili ang user ng indibidwal na application. Gaano kasimple!

Mukhang marami sa mga saklay at workaround na kinakailangan ng AppImage sa Linux ang nagiging hindi na kailangan sa Haiku, na kung saan ay ang pagiging simple at pagiging sopistikado sa kanyang pangunahing dahilan upang mapangasiwaan ang karamihan sa aming mga pangangailangan.

Kailangan ba ng Haiku ang mga pakete ng app pagkatapos ng lahat?

Ito ay humahantong sa isang malaking katanungan. Kung mas madaling gumawa ng system tulad ng AppImage sa Haiku kaysa sa Linux, sulit ba itong gawin? O epektibo bang inalis ng Haiku, kasama ang sistema ng pakete ng hpkg nito, ang pangangailangang bumuo ng gayong ideya? Well, upang masagot kailangan nating tingnan ang motibasyon sa likod ng pagkakaroon ng AppImages.

Perspektibo ng gumagamit

Tingnan natin ang aming end user:

• Gusto kong mag-install ng application nang hindi humihingi ng administrator (root) password. Walang konsepto ng isang administrator sa Haiku, ang user ay may ganap na kontrol dahil ito ay isang personal na sistema! (Sa prinsipyo, maaari mong isipin ito sa multiplayer mode, inaasahan kong panatilihin itong simple ng mga developer)
• Gusto kong makuha ang pinakabago at pinakadakilang mga bersyon ng mga application, nang hindi naghihintay na lumitaw ang mga ito sa aking pamamahagi (madalas na nangangahulugan ito na "hindi", kahit na maliban kung i-update ko ang buong operating system). Sa Haiku ito ay "nalutas" sa mga lumulutang na release. Nangangahulugan ito na posible na makuha ang pinakabago at pinakamahusay na mga bersyon ng mga application, ngunit upang magawa ito kailangan mong patuloy na i-update ang natitirang bahagi ng system, na epektibong gawing isang "gumagalaw na target".
• Gusto ko ng ilang mga bersyon ng parehong application na magkatabi, dahil walang paraan upang malaman kung ano ang nasira sa pinakabagong bersyon, o, sabihin nating, ako, bilang isang web developer, ay kailangang subukan ang aking trabaho sa ilalim ng iba't ibang mga bersyon ng browser. Niresolba ng Haiku ang unang problema, ngunit hindi ang pangalawa. Ang mga pag-update ay ibinalik, ngunit para lamang sa buong system; imposible (sa pagkakaalam ko) na tumakbo, halimbawa, ilang mga bersyon ng WebPositive o LibreOffice nang sabay-sabay.

Isinulat ng isa sa mga developer:

Sa esensya ang katwiran ay ito: ang kaso ng paggamit ay napakabihirang na ang pag-optimize para dito ay walang saysay; ang pagtrato dito bilang isang espesyal na kaso sa HaikuPorts ay tila higit pa sa katanggap-tanggap.

• Kailangan kong panatilihin ang mga app kung saan ko gusto ang mga ito, hindi sa aking startup drive. Madalas akong nauubusan ng puwang sa disk, kaya kailangan kong ikonekta ang isang panlabas na drive o direktoryo ng network upang mag-imbak ng mga application (lahat ng mga bersyon na na-download ko). Kung ikinonekta ko ang naturang drive, kailangan ko ng mga application na ilulunsad sa pamamagitan ng pag-double click. Ang Haiku ay nagse-save ng mga lumang bersyon ng mga pakete, ngunit hindi ko alam kung paano ilipat ang mga ito sa isang panlabas na drive, o kung paano maglunsad ng mga application mula doon sa ibang pagkakataon.

Komento ng developer:

Sa teknikal, posible na ito sa mount command. Siyempre, gagawa kami ng GUI para dito sa sandaling magkaroon kami ng sapat na mga interesadong user.

• Hindi ko kailangan ng milyun-milyong file na nakakalat sa file system na hindi ko manwal na pamahalaan ang aking sarili. Gusto ko ng isang file sa bawat application na madali kong mada-download, mailipat, matanggal. Sa Haiku ang problemang ito ay nalutas gamit ang mga pakete .hpkg, na naglilipat, halimbawa, python, mula sa libu-libong mga file sa isa. Ngunit kung mayroong, halimbawa, Scribus gamit ang python, pagkatapos ay kailangan kong harapin ang hindi bababa sa dalawang mga file. At kailangan kong mag-ingat na panatilihin ang mga bersyon ng mga ito na gumagana sa isa't isa.

Maramihang bersyon ng AppImages na tumatakbong magkatabi sa parehong Linux

Ang pananaw ng isang developer ng application

Tingnan natin mula sa pananaw ng isang developer ng application:

• Gusto kong kontrolin ang buong karanasan ng user. Hindi ko gustong umasa sa isang operating system para sabihin sa akin kung kailan at paano ako dapat maglabas ng mga application. Hinahayaan ng Haiku ang mga developer na magtrabaho kasama ang kanilang sariling mga repositoryo ng hpkg, ngunit nangangahulugan ito na kakailanganing i-set up ng mga user ang mga ito nang manu-mano, na ginagawang "hindi gaanong kaakit-akit" ang ideya.
• Mayroon akong pahina ng pag-download sa aking website kung saan ako namamahagi .exe para sa Windows, .dmg para sa Mac at .AppImage para sa Linux. O baka gusto kong pagkakitaan ang pag-access sa page na ito, kahit ano ay posible? Ano ang dapat kong ilagay doon para kay Haiku? Ang file ay sapat na .hpkg na may mga dependency lamang mula sa HaikuPorts
• Ang aking software ay nangangailangan ng mga partikular na bersyon ng iba pang software. Halimbawa, alam na ang Krita ay nangangailangan ng isang patched na bersyon ng Qt, o Qt na fine-tune sa isang partikular na bersyon ng Krita, hindi bababa sa hanggang sa ang mga patch ay itulak pabalik sa Qt. Maaari mong i-package ang iyong sariling Qt para sa iyong aplikasyon sa isang pakete .hpkg, ngunit malamang na hindi ito malugod.

Regular na pahina ng pag-download ng application. Ano ang dapat kong i-post dito para sa Haiku?

Will bundle (umiiral bilang mga direktoryo ng application tulad ng AppDir o .app sa Apple style) at/o mga imahe (sa anyo ng lubos na binagong AppImages o .dmg mula sa Apple) na mga application ng isang kapaki-pakinabang na karagdagan sa Haiku desktop environment? O magpapalabnaw ba ito sa buong larawan at hahantong sa pagkapira-piraso, at samakatuwid ay magdaragdag ng pagiging kumplikado? Ako ay napunit: sa isang banda, ang kagandahan at pagiging sopistikado ng Haiku ay nakabatay sa katotohanan na kadalasan ay may isang paraan upang gawin ang isang bagay, kaysa sa marami. Sa kabilang banda, ang karamihan sa mga imprastraktura para sa mga katalogo at/o mga suite ng aplikasyon ay nasa lugar na, kaya ang sistema ay sumisigaw na ang natitirang ilang porsyento ay mahuhulog sa lugar.

Ayon sa developer Ginoo. waddlesplash

Sa Linux sila (mga katalogo at application kit, - tantiya. tagasalin) ay malamang na isang teknikal na solusyon sa mga sistematikong problema. Sa Haiku mas gusto naming lutasin lang ang mga problema sa system.

Ano sa tingin mo?

Bago ka sumagot...

Maghintay, gawin natin ang isang mabilis na pagsusuri sa katotohanan: sa katunayan mga direktoryo ng aplikasyon - bahagi na ng Haiku:

Umiiral na ang mga direktoryo ng application sa Haiku, ngunit hindi pa sinusuportahan sa file manager

Ang mga ito ay hindi gaanong suportado gaya ng, halimbawa, ang Macintosh Finder. Gaano kaganda kung ang direktoryo ng QtCreator ay may pangalan at icon na "QtCreator" sa kaliwang sulok sa itaas, na naglulunsad ng application kapag na-double click?

Medyo kanina pa ako nagtanong:

Sigurado ka bang maaari mong patakbuhin ang iyong mga decade-old na app ngayon kapag nakalimutan na ng lahat ng app store at distribution repository ang tungkol sa kanila at sa kanilang mga dependency? Kumpiyansa ka ba na maa-access mo pa rin ang iyong kasalukuyang trabaho sa hinaharap?

Mayroon na bang sagot mula sa Haiku, o makakatulong ba dito ang mga katalogo at mga bundle ng application? Sa tingin ko kaya nila.

Ayon kay mr. waddlesplash:

Oo, nasa amin ang sagot sa tanong: susuportahan lang namin ang mga application na ito hangga't kinakailangan hanggang sa mabasa ng isang tao ang kanilang mga format ng file sa tamang paraan o magbigay ng one-to-one na functionality. Ang aming pangako sa pagsuporta sa BeOS R5 app sa Haiku ay patunay nito...

Ito ay sigurado!

Anong hakbang ang dapat gawin ni Haiku?

Naiisip ko ang mapayapang magkakasamang buhay ng hpkg, mga direktoryo at mga larawan ng aplikasyon:

• Gumagamit ng software ng system .hpkg
• Para sa pinakamadalas na ginagamit na software (lalo na sa mga kailangang mag-iskedyul ng mga rolling release), gamitin .hpkg (humigit-kumulang 80% ng lahat ng kaso)
• Ang ilan ay naka-install sa pamamagitan ng .hpkg, makikinabang ang mga application mula sa paglipat sa isang imprastraktura ng direktoryo ng aplikasyon (hal. QtCreator): ipapamahagi sila bilang .hpkg, tulad ng dati.

Ginoo. isinulat ni waddlesplash:

Kung ang kailangan mo lang ay tingnan ang mga application /system/apps, sa halip ay dapat nating gawing mas madaling pamahalaan ang mga direktoryo sa Deskbar para sa mga user, dahil /system/apps ay hindi nilayon na regular na buksan at tingnan ng mga user (hindi katulad ng MacOS). Para sa mga ganitong sitwasyon, ang Haiku ay may ibang paradigm, ngunit ang pagpipiliang ito, sa teorya, ay katanggap-tanggap.

• Natatanggap ng Haiku ang imprastraktura para sa pagpapatakbo ng mga larawan ng application, gabi-gabi, tuluy-tuloy at pagsubok na pagbuo ng software, pati na rin para sa mga kaso kung kailan gusto ng user na "i-freeze ito sa oras", para sa pribado at panloob na software, at iba pang mga espesyal na kaso ng paggamit (mga 20% sa lahat). Ang mga larawang ito ay naglalaman ng mga file na kinakailangan upang patakbuhin ang application .hpkg, na-mount ng system, at pagkatapos makumpleto ang application - hindi naka-mount. (Marahil ang isang file manager ay maaaring maglagay ng mga file .hpkg sa mga larawan ng application, awtomatiko o sa kahilingan ng gumagamit - mabuti, tulad ng kapag nag-drag ka ng isang application sa isang direktoryo ng network o panlabas na drive. Kanta lang yan! O sa halip, tula - haiku.) Sa kabilang banda, maaaring gusto ng user na i-install ang mga nilalaman ng imahe sa anyo ng mga file.hpkg, pagkatapos nito ay ia-update at ipoproseso ang mga ito sa parehong paraan na parang na-install sila sa pamamagitan ng HaikuDepot... Kailangan nating mag-brainstorm).

Quote mula kay mr. waddlesplash:

Ang pagpapatakbo ng mga application mula sa mga panlabas na drive o mga direktoryo ng network ay maaaring maging kapaki-pakinabang. At ang pagdaragdag ng kakayahang mag-configure ng higit pang "mga zone" para sa pkgman ay tiyak na isang magandang tampok.

Ang ganitong sistema ay sasamantalahin ang hpkg, mga direktoryo, at mga larawan ng aplikasyon. Ang mga ito ay mahusay na indibidwal, ngunit magkasama sila ay magiging walang talo.

Konklusyon

May framework ang Haiku na nagbibigay ng simple at sopistikadong karanasan ng user para sa PC, at higit pa sa karaniwang ibinibigay para sa Linux PC. Sistema ng package .hpkg ay isa sa gayong halimbawa, ngunit ang natitirang bahagi ng sistema ay puno rin ng pagiging sopistikado. Gayunpaman, makikinabang ang Haiku mula sa wastong direktoryo at suporta sa imahe ng application. Kung paano pinakamahusay na gawin ito ay nagkakahalaga ng pagtalakay sa mga taong nakakaalam ng Haiku, ang pilosopiya at arkitektura nito na mas mahusay kaysa sa akin. Tutal, mahigit isang linggo na akong gumagamit ng Haiku. Gayunpaman, naniniwala ako na ang mga taga-disenyo, developer, at arkitekto ng Haiku ay makikinabang sa bagong pananaw na ito. At least, magiging masaya akong maging “sparring partner” nila. Mayroon akong higit sa 10 taon ng hands-on na karanasan sa mga katalogo at bundle ng Linux application, at gusto kong makahanap ng gamit para sa mga ito sa Haiku, kung saan sa tingin ko ay akmang-akma ang mga ito. Ang mga potensyal na solusyon na aking iminungkahi ay hindi lamang ang mga tama para sa mga problemang inilarawan ko, at kung ang Haiku team ay magpasya na maghanap ng iba, mas eleganteng mga solusyon, ako ay para dito. Talaga, iniisip ko na ang ideya kung paano gumawa ng isang sistema hpkg mas kamangha-mangha nang hindi binabago ang paraan ng paggana nito. Lumalabas na matagal nang nag-iisip ang pangkat ng Haiku tungkol sa mga bundle ng aplikasyon kapag nagpapatupad ng sistema ng pamamahala ng package, ngunit sa kasamaang-palad (sa tingin ko) ang ideya ay naging "lipas na". Siguro oras na para buhayin ito?

Subukan ito sa iyong sarili! Pagkatapos ng lahat, ang proyekto ng Haiku ay nagbibigay ng mga larawan para sa pag-boot mula sa DVD o USB, na nabuo araw-araw.
May tanong ka ba? Inaanyayahan ka namin sa nagsasalita ng Ruso channel ng telegram.

Pangkalahatang-ideya ng error: Paano i-shoot ang iyong sarili sa paa sa C at C++. Koleksyon ng mga recipe ng Haiku OS

Mula sa may-akda pagsasalin: ito ang ikawalo at huling artikulo sa serye tungkol sa Haiku.

Listahan ng mga artikulo: Muna Ang pangalawang Ang ikatlo Pang-apat Pang-lima Ika-anim Ikapito

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Makatuwiran bang i-port ang hpkg system sa Linux?

• Oo

• Hindi

• Naipatupad na, magsusulat ako sa mga komento

20 user ang bumoto. 5 na user ang umiwas.

Pinagmulan: www.habr.com