🥇Sesuatu yang lain: Pakej aplikasi Haiku?

TL; DR: Bolehkah Haiku mendapatkan sokongan yang sesuai untuk pakej aplikasi, seperti direktori aplikasi (seperti .app dalam Mac) dan/atau imej aplikasi (Linux AppImage)? Saya fikir ini akan menjadi tambahan yang berbaloi yang lebih mudah untuk dilaksanakan dengan betul daripada sistem lain kerana kebanyakan infrastruktur sudah sedia ada.

Seminggu yang lalu Saya menemui Haiku, sistem yang tidak disangka-sangka baik. Nah, kerana saya telah lama berminat dengan direktori dan imej aplikasi (diilhamkan oleh kesederhanaan Macintosh), tidak hairanlah idea muncul di fikiran saya...

Untuk rekod, saya pencipta dan pengarang AppImage, format pengedaran aplikasi. Linux, yang bertujuan untuk menjadikan Mac lebih mudah dan meletakkan kawalan sepenuhnya di tangan pengarang aplikasi dan pengguna akhir (lihat lebih lanjut di bawah). wiki и dokumentasi).

Bagaimana jika kita membuat AppImage untuk Haiku?

Mari kita berfikir sedikit, secara teori semata-mata: apa yang perlu dilakukan untuk mendapatkannya AppImage, atau sesuatu yang serupa, pada Haiku? Tidak perlu mencipta sesuatu sekarang, kerana sistem Haiku sudah berfungsi dengan menakjubkan, tetapi eksperimen khayalan adalah lebih baik. Ia juga menunjukkan kecanggihan Haiku berbanding persekitaran desktop. Linux, di mana perkara sedemikian sangat sukar (saya berhak mengatakan ini: Saya telah bergelut dengan penyahpepijatan selama 10 tahun).

Pada Sistem Macintosh 1, setiap aplikasi merupakan fail berasingan, "diuruskan" dalam Finder. Menggunakan AppImage, saya cuba mencipta semula pengalaman pengguna yang sama pada Linux.

Pertama, apakah itu AppImage? Ini ialah sistem untuk mengeluarkan aplikasi pihak ketiga (contohnya, Penawar Ultimaker), membenarkan aplikasi dikeluarkan bila dan bagaimana mereka mahu: tidak perlu mengetahui spesifik pelbagai pengedaran, membina dasar atau membina infrastruktur, tiada sokongan penyelenggara diperlukan dan mereka tidak memberitahu pengguna apa yang (tidak) mereka boleh pasang pada komputer mereka. AppImage harus difahami sebagai sesuatu yang serupa dengan pakej Mac dalam format .app di dalam imej cakera .dmg. Perbezaan utama ialah aplikasi tidak disalin, tetapi kekal di dalam AppImage selama-lamanya, sama seperti pakej Haiku .hpkg dipasang, dan tidak pernah dipasang dalam erti kata biasa.

Sepanjang lebih 10 tahun kewujudannya, AppImage telah mendapat sedikit tarikan dan populariti: Linus Torvalds sendiri telah menyokongnya secara terbuka, dan projek popular (contohnya, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) telah menerima pakainya sebagai kaedah utama untuk mengedarkan binaan berterusan atau setiap malam yang tidak mengganggu aplikasi yang dipasang atau dinyahpasang pengguna. Walau bagaimanapun, persekitaran dan pengedaran desktop Linux selalunya masih berpegang teguh pada model pengedaran berpusat tradisional berdasarkan penyelenggara dan/atau mempromosikan perniagaan korporat dan/atau program kejuruteraan mereka sendiri berdasarkan Flatpak (RedHat, Fedora, GNOME) dan Snappy (Kanonik, UbuntuIa semakin hampir. mengarut.

Bagaimana ia berfungsi

Setiap AppImage mengandungi 2 bahagian: klik dua kali kecil ELF (kononnya. runtime.c), diikuti dengan imej sistem fail SkuasyFS.

Sistem fail SquashFS mengandungi muatan dalam bentuk aplikasi dan semua yang diperlukan untuk menjalankannya, yang dalam fikiran waras tidak boleh dianggap sebagai sebahagian daripada pemasangan lalai untuk setiap sistem sasaran (pengedaran) yang cukup terkini. Linux). Ia juga mengandungi metadata, seperti nama aplikasi, ikon, jenis MIME, dsb.

Apabila dijalankan oleh pengguna, masa jalan menggunakan FUSE dan squashfuse untuk melekapkan sistem fail, dan kemudian mengendalikan menjalankan beberapa titik masuk (aka AppRun) di dalam AppImage yang dipasang.
Sistem fail dinyahlekap selepas proses selesai.

Semuanya nampak mudah.

Dan perkara-perkara ini merumitkan segala-galanya:

dengan pelbagai pengedaran sedemikian Linux Tiada apa-apa pun dalam keadaan waras yang boleh dipanggil "sebahagian daripada pemasangan lalai untuk setiap sistem sasaran baharu" lagi. Kita dapat mengatasi masalah ini dengan membina excludelist, membolehkan anda menentukan perkara yang akan dibungkus dalam AppImage dan perkara yang perlu dibawa ke tempat lain. Pada masa yang sama, kita kadang-kadang terlepas, walaupun pada hakikatnya, secara umum, semuanya berfungsi dengan baik. Atas sebab ini, kami mengesyorkan agar pencipta pakej menguji AppImages pada semua sistem sasaran (pengedaran).
Muatan aplikasi mesti boleh dipindahkan ke seluruh sistem fail. Malangnya, banyak aplikasi mempunyai laluan mutlak berkod keras ke, sebagai contoh, sumber dalam /usr/share. Ini perlu diperbaiki entah bagaimana. Di samping itu, anda mesti sama ada mengeksport LD_LIBRARY_PATH, atau betulkan rpath supaya pemuat boleh mencari perpustakaan berkaitan. Kaedah pertama mempunyai kelemahannya (yang diatasi dengan cara yang kompleks), dan yang kedua hanya menyusahkan.
Perangkap UX terbesar untuk pengguna ialah itu tetapkan bit boleh laku Fail AppImage selepas dimuat turun. Percaya atau tidak, ini adalah halangan sebenar bagi sesetengah orang. Menetapkan bit boleh laku adalah rumit walaupun untuk pengguna yang berpengalaman. Sebagai penyelesaian, kami mencadangkan memasang perkhidmatan kecil yang memantau fail AppImage dan menetapkan bit boleh laku mereka. Dalam bentuk tulennya, ini bukanlah penyelesaian terbaik, kerana ia tidak akan berfungsi begitu sahaja. Pengedaran Linux Mereka tidak menyediakan perkhidmatan ini, jadi pengguna mempunyai pengalaman buruk sejak awal.
Ahli Linux Mereka menjangkakan aplikasi baharu mempunyai ikon dalam pelancar. Anda tidak boleh hanya berkata kepada sistem, "Tengok, ada aplikasi baharu, mari kita mulakan." Sebaliknya, mengikut spesifikasi XDG, anda perlu menyalin fail tersebut. .desktop ke tempat yang betul dalam /usr untuk pemasangan seluruh sistem, atau dalam $HOME untuk individu. Ikon saiz tertentu, mengikut spesifikasi XDG, perlu diletakkan di tempat tertentu usr atau $HOME, dan kemudian jalankan arahan dalam persekitaran kerja untuk mengemas kini cache ikon, atau berharap pengurus persekitaran kerja akan memikirkannya dan secara automatik mengesan segala-galanya. Sama dengan jenis MIME. Sebagai penyelesaian, dicadangkan untuk menggunakan perkhidmatan yang sama, yang, sebagai tambahan kepada menetapkan bendera kebolehlaksanaan, akan, jika terdapat ikon, dsb. dalam AppImage, salinnya daripada AppImage ke tempat yang betul mengikut XDG. Apabila dipadamkan atau dialihkan, perkhidmatan itu dijangka akan mengosongkan segala-galanya. Sudah tentu, terdapat perbezaan dalam tingkah laku setiap persekitaran kerja, dalam format fail grafik, saiznya, lokasi storan dan kaedah untuk mengemas kini cache, yang menimbulkan masalah. Pendek kata, kaedah ini adalah tongkat.
Jika itu tidak mencukupi, masih tiada ikon AppImage dalam pengurus fail. Linux masih belum membuat keputusan untuk melaksanakan elficon (walaupun perbincangan и pelaksanaan), jadi adalah mustahil untuk membenamkan ikon terus ke dalam aplikasi. Jadi ternyata aplikasi dalam pengurus fail tidak mempunyai ikon mereka sendiri (tiada perbezaan, AppImage atau sesuatu yang lain), mereka hanya dalam menu mula. Sebagai penyelesaian, kami menggunakan lakaran kenit, mekanisme yang pada asalnya direka bentuk untuk membolehkan pengurus desktop menunjukkan imej pratonton lakaran kecil bagi fail grafik sebagai ikon mereka. Akibatnya, perkhidmatan untuk menetapkan bit kebolehlaksanaan juga berfungsi sebagai "pengecil", mencipta dan menulis lakaran kecil ikon ke lokasi yang sesuai /usr и $HOME. Perkhidmatan ini juga melakukan pembersihan jika AppImage dipadamkan atau dialihkan. Disebabkan hakikat bahawa setiap pengurus desktop berkelakuan sedikit berbeza, contohnya, dalam format apa ia menerima ikon, dalam saiz atau tempat apa, ini semua sangat menyakitkan.
Aplikasi hanya ranap pada pelaksanaan jika ralat berlaku (contohnya, terdapat perpustakaan yang bukan sebahagian daripada sistem asas dan tidak dibekalkan dalam AppImage), dan tiada siapa yang memberitahu pengguna dalam GUI apa sebenarnya yang berlaku. Kami mula mengatasi ini dengan menggunakan pemberitahuan pada desktop, yang bermaksud kita perlu menangkap ralat daripada baris arahan, menukarnya kepada mesej yang difahami pengguna, yang kemudiannya perlu dipaparkan pada desktop. Dan sudah tentu, setiap persekitaran desktop mengendalikannya sedikit berbeza.
Pada masa ini (September 2019 - nota penterjemah) saya tidak menemui cara mudah untuk memberitahu sistem bahawa fail 1.png mesti dibuka menggunakan Krita, dan 2.png - menggunakan GIMP.

Lokasi storan untuk spesifikasi merentas desktop yang digunakan dalam GNOME, KDE и Xfce ialah freedesktop.org

Mencapai tahap kecanggihan yang dijalin secara mendalam ke dalam persekitaran kerja Haiku adalah sukar, jika tidak mustahil, disebabkan oleh spesifikasi XDG daripada freedesktop.org untuk merentas desktop, serta pelaksanaan pengurus desktop berdasarkan spesifikasi ini. Sebagai contoh, kita boleh memetik satu ikon Firefox seluruh sistem: nampaknya, pengarang XDG tidak menyangka bahawa pengguna boleh memasang beberapa versi aplikasi yang sama.

Ikon untuk versi Firefox yang berbeza

Aku tertanya-tanya apa itu dunia Linux Saya boleh belajar daripada Mac OS X untuk mengelakkan kerosakan pada integrasi sistem. Jika anda mempunyai masa dan terlibat dalam perkara ini, pastikan anda membaca apa yang dikatakan oleh Arnaud Gourdold, salah seorang jurutera Mac OS X yang pertama:

Kami mahu menjadikan pemasangan aplikasi semudah menyeret ikon aplikasi dari suatu tempat (pelayan, pemacu luaran) ke pemacu komputer anda. Untuk melakukan ini, pakej aplikasi menyimpan semua maklumat, termasuk ikon, versi, jenis fail yang sedang diproses, jenis skema URL yang perlu diketahui oleh sistem untuk memproses aplikasi. Ini juga termasuk maklumat untuk 'storan pusat' dalam pangkalan data Perkhidmatan Ikon dan Perkhidmatan Pelancaran. Untuk menyokong prestasi, aplikasi 'ditemui' di beberapa tempat 'terkenal': sistem dan direktori Aplikasi pengguna, dan beberapa yang lain secara automatik jika pengguna menavigasi ke Finder dalam direktori yang mengandungi aplikasi. Dalam amalan ini berfungsi dengan baik.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesi 144 - Mac OS X: aplikasi pembungkusan dan dokumen percetakan.

Tiada apa yang serupa daripada infrastruktur ini dalam persekitaran pengeluaran. Linux, jadi kami sedang mencari jalan penyelesaian sekitar batasan struktur dalam projek AppImage.

Adakah Haiku datang untuk menyelamatkan?

Dan juga: platform Linux sebagai asas persekitaran kerja, biasanya kurang dinyatakan sehingga banyak perkara yang agak mudah dalam sistem tindanan penuh yang koheren menjadi berpecah-belah dan kompleks yang mengecewakan LinuxSaya mendedikasikan keseluruhan laporan untuk isu-isu berkaitan platform ini. Linux untuk persekitaran kerja (pembangun yang berpengetahuan telah mengesahkan bahawa semuanya akan kekal seperti ini untuk masa yang sangat lama).

Laporan saya tentang masalah persekitaran kerja Linux dalam 2018

Malah Linus Torvalds mengakui bahawa pemecahan adalah sebab idea ruang kerja gagal.

Seronok dapat jumpa Haiku!

Haiku menjadikan segala-galanya sangat mudah

Walaupun pendekatan naif untuk "memindahkan" AppImage ke Haiku adalah dengan hanya cuba mengkompilasi komponennya (terutamanya runtime.c dan perkhidmatan) (yang mungkin boleh dilakukan!), ini tidak akan membawa banyak manfaat kepada Haiku. Kerana, sebenarnya, kebanyakan masalah ini diselesaikan dalam Haiku dan kukuh dari segi konsep. Haiku menyediakan blok binaan untuk infrastruktur sistem yang telah saya cari dalam persekitaran desktop sejak sekian lama. Linux dan tidak percaya mereka tiada di sana. Iaitu:

Percaya atau tidak, ramai pengguna tidak dapat mengatasi perkara ini. LinuxDi Haiku, semuanya dilakukan secara automatik!

Fail ELF yang tidak mempunyai bit kebolehlaksanaan mendapat satu secara automatik apabila diklik dua kali dalam pengurus fail.
Aplikasi boleh mempunyai sumber terbina dalam, seperti ikon, yang dipaparkan dalam pengurus fail. Tidak perlu menyalin sekumpulan imej ke dalam direktori khas dengan ikon, dan oleh itu tidak perlu membersihkannya selepas memadam atau mengalihkan aplikasi.
Terdapat pangkalan data untuk menghubungkan aplikasi dengan dokumen, tidak perlu menyalin sebarang fail untuk ini.
Dalam direktori lib/ bersebelahan dengan fail boleh laku, perpustakaan dicari secara lalai.
Tidak terdapat banyak pengedaran dan persekitaran desktop; apa sahaja yang berfungsi, berfungsi di mana-mana sahaja.
Tiada modul berasingan untuk dijalankan yang berbeza daripada direktori Aplikasi.
Aplikasi tidak mempunyai laluan mutlak terbina dalam ke sumber mereka; mereka mempunyai fungsi khas untuk menentukan lokasi semasa runtime.
Idea imej sistem fail termampat telah diperkenalkan: ini adalah sebarang pakej hpkg. Kesemuanya dipasang oleh kernel.
Setiap fail dibuka oleh aplikasi yang menciptanya, melainkan anda menyatakan sebaliknya secara eksplisit. Sungguh keren ini!

Dua fail png. Perhatikan ikon berbeza yang menunjukkan bahawa ia akan dibuka oleh aplikasi yang berbeza apabila diklik dua kali. Juga perhatikan menu lungsur turun "Buka dengan:" di mana pengguna boleh memilih aplikasi individu. Betapa mudahnya!

Nampaknya banyak petua dan penyelesaian yang diperlukan oleh AppImage pada Linux, menjadi tidak perlu pada Haiku, yang pada terasnya mempunyai kesederhanaan dan kecanggihan yang menjadikannya sesuai untuk kebanyakan keperluan kita.

Adakah Haiku memerlukan pakej aplikasi?

Ini membawa saya kepada persoalan besar: Jika mencipta sistem seperti AppImage pada Haiku adalah satu peringkat magnitud yang lebih mudah berbanding pada Linux, adakah ia berbaloi untuk diteruskan? Atau adakah Haiku, dengan sistem pembungkusan hpkgnya, telah berkesan menghapuskan keperluan untuk idea sedemikian? Nah, untuk menjawabnya, kita perlu melihat motivasi di sebalik AppImages.

Perspektif pengguna

Mari lihat pengguna akhir kami:

Saya mahu memasang aplikasi tanpa meminta kata laluan pentadbir (root). Tiada konsep pentadbir pada Haiku, pengguna mempunyai kawalan penuh kerana ia adalah sistem peribadi! (Secara prinsipnya, anda boleh bayangkan ini dalam mod berbilang pemain, saya harap pemaju membuatnya mudah)
Saya ingin mendapatkan versi aplikasi terkini dan terhebat, tanpa menunggu ia muncul dalam pengedaran saya (selalunya ini bermakna "tidak pernah", sekurang-kurangnya melainkan saya mengemas kini keseluruhan sistem pengendalian). Pada Haiku ini "diselesaikan" dengan keluaran terapung. Ini bermakna bahawa adalah mungkin untuk mendapatkan versi aplikasi terkini dan terbaik, tetapi untuk melakukan ini, anda perlu sentiasa mengemas kini seluruh sistem, dengan berkesan mengubahnya menjadi "sasaran bergerak".
Saya mahu beberapa versi aplikasi yang sama bersebelahan, kerana tidak ada cara untuk mengetahui perkara yang rosak dalam versi terkini, atau, katakan, saya, sebagai pembangun web, perlu menguji kerja saya di bawah versi penyemak imbas yang berbeza. Haiku menyelesaikan masalah pertama, tetapi bukan yang kedua. Kemas kini digulung semula, tetapi hanya untuk keseluruhan sistem; adalah mustahil (setahu saya) untuk dijalankan, sebagai contoh, beberapa versi WebPositive atau LibreOffice pada masa yang sama.

Salah seorang pemaju menulis:

Pada asasnya rasionalnya ialah ini: kes penggunaan sangat jarang berlaku sehingga mengoptimumkannya tidak masuk akal; menganggapnya sebagai kes istimewa dalam HaikuPorts nampaknya lebih daripada boleh diterima.

Saya perlu menyimpan apl di tempat yang saya sukai, bukan pada pemacu permulaan saya. Saya sering kehabisan ruang cakera, jadi saya perlu menyambungkan pemacu luaran atau direktori rangkaian untuk menyimpan aplikasi (semua versi yang telah saya muat turun). Jika saya menyambung pemacu sedemikian, saya memerlukan aplikasi untuk dilancarkan dengan mengklik dua kali. Haiku menyimpan versi lama pakej, tetapi saya tidak tahu cara mengalihkannya ke pemacu luaran atau cara melancarkan aplikasi dari sana kemudian.

Komen pembangun:

Secara teknikal, ini sudah boleh dilakukan dengan arahan mount. Sudah tentu, kami akan membuat GUI untuk ini sebaik sahaja kami mempunyai cukup pengguna yang berminat.

Saya tidak memerlukan berjuta-juta fail yang bertaburan di seluruh sistem fail yang saya tidak boleh mengurus sendiri secara manual. Saya mahu satu fail bagi setiap aplikasi yang saya boleh muat turun, alih, padam dengan mudah. Pada Haiku masalah ini diselesaikan menggunakan pakej .hpkg, yang memindahkan, sebagai contoh, python, daripada beribu-ribu fail kepada satu. Tetapi jika ada, sebagai contoh, Scribus menggunakan python, maka saya perlu berurusan dengan sekurang-kurangnya dua fail. Dan saya perlu berhati-hati untuk mengekalkan versi mereka yang berfungsi antara satu sama lain.

Pelbagai versi AppImages berjalan bersebelahan pada satu Linux

Perspektif pembangun aplikasi

Mari kita lihat dari sudut pandangan pembangun aplikasi:

Saya mahu mengawal keseluruhan pengalaman pengguna. Saya tidak mahu bergantung pada sistem pengendalian untuk memberitahu saya bila dan bagaimana saya perlu mengeluarkan aplikasi. Haiku membenarkan pembangun bekerja dengan repositori hpkg mereka sendiri, tetapi ini bermakna pengguna perlu menyediakannya secara manual, yang menjadikan idea itu "kurang menarik."
Saya mempunyai halaman muat turun di tapak web saya tempat saya mengedarkan .exe untuk Windows, .dmg untuk Mac dan .AppImage untuk LinuxAtau mungkin saya ingin menjana wang daripada akses ke halaman ini? Apa sahaja boleh dilakukan? Apa yang perlu saya letakkan di sana untuk Haiku? Fail sudah memadai .hpkg dengan kebergantungan hanya dari HaikuPorts
Perisian saya memerlukan versi khusus perisian lain. Sebagai contoh, diketahui bahawa Krita memerlukan versi tampalan Qt, atau Qt yang diperhalusi kepada versi Krita tertentu, sekurang-kurangnya sehingga tampalan ditolak semula ke dalam Qt. Anda boleh membungkus Qt anda sendiri untuk aplikasi anda dalam pakej .hpkg, tetapi kemungkinan besar ini tidak dialu-alukan.

Halaman muat turun aplikasi biasa. Apakah yang perlu saya siarkan di sini untuk Haiku?

Will bundles (sedia ada sebagai direktori aplikasi seperti AppDir atau .app dalam gaya Apple) dan/atau imej (dalam bentuk AppImages yang banyak diubah suai atau .dmg daripada Apple) menggunakan tambahan berguna kepada persekitaran desktop Haiku? Atau adakah ia akan mencairkan keseluruhan gambar dan membawa kepada pemecahan, dan oleh itu menambah kerumitan? Saya terkoyak: dalam satu pihak, keindahan dan kecanggihan Haiku adalah berdasarkan fakta bahawa biasanya terdapat satu cara untuk melakukan sesuatu, bukannya banyak. Sebaliknya, kebanyakan infrastruktur untuk katalog dan/atau suite aplikasi sudah sedia ada, jadi sistem meminta baki beberapa peratus untuk digunakan.

Menurut pemaju Encik. waddlesplash

Pada Linux Mereka (katalog dan kit aplikasi, - lebih kurang. penterjemah) kemungkinan besar merupakan penyelesaian teknikal kepada masalah sistemik. Di Haiku kami lebih suka menyelesaikan masalah sistem sahaja.

Apa pendapat kamu?

Sebelum anda menjawab...

Tunggu, mari kita buat semakan realiti pantas: sebenarnya direktori aplikasi - sudah menjadi sebahagian daripada Haiku:

Direktori aplikasi sudah wujud pada Haiku, tetapi belum lagi disokong dalam pengurus fail

Mereka tidak disokong dengan baik seperti, katakan, Pencari Macintosh. Betapa hebatnya jika direktori QtCreator mempunyai nama dan ikon "QtCreator" di penjuru kiri sebelah atas, melancarkan aplikasi apabila diklik dua kali?

Sedikit lebih awal saya sudah bertanya:

Adakah anda pasti anda boleh menjalankan apl berusia sedekad anda hari ini apabila semua kedai aplikasi dan repositori pengedaran telah melupakannya dan kebergantungannya? Adakah anda yakin bahawa anda masih boleh mengakses pekerjaan semasa anda pada masa hadapan?

Adakah sudah ada jawapan daripada Haiku, atau bolehkah katalog dan himpunan aplikasi membantu di sini? Saya rasa mereka boleh.

Menurut mr. waddlesplash:

Ya, kami mempunyai jawapan kepada soalan itu: kami hanya akan menyokong aplikasi ini selama yang diperlukan sehingga seseorang boleh membaca format fail mereka dengan cara yang betul atau menyediakan fungsi satu sama satu. Komitmen kami untuk menyokong aplikasi BeOS R5 di Haiku adalah buktinya...

Ini pasti!

Apakah tindakan yang perlu diambil oleh Haiku?

Saya boleh bayangkan kewujudan damai hpkg, direktori dan imej aplikasi:

Kegunaan perisian sistem .hpkg
Untuk perisian yang paling kerap digunakan (terutamanya yang perlu menjadualkan keluaran rolling), gunakan .hpkg (kira-kira 80% daripada semua kes)
Beberapa dipasang melalui .hpkg, aplikasi akan mendapat manfaat daripada berpindah ke infrastruktur direktori aplikasi (cth QtCreator): ia akan diedarkan sebagai .hpkg, seperti dahulu.

Encik. waddlesplash menulis:

Jika anda hanya perlu melihat aplikasi dalam /system/apps, sebaliknya kita harus menjadikan direktori dalam Deskbar lebih mudah diurus untuk pengguna, kerana /system/apps tidak bertujuan untuk dibuka dan dilihat secara kerap oleh pengguna (tidak seperti MacOS). Untuk situasi sedemikian, Haiku mempunyai paradigma yang berbeza, tetapi pilihan ini, secara teori, boleh diterima.

Haiku menerima infrastruktur untuk menjalankan imej aplikasi, binaan perisian setiap malam, berterusan dan ujian, serta untuk kes apabila pengguna mahu "membekukannya dalam masa", untuk perisian peribadi dan dalaman, dan kes penggunaan khas lain (kira-kira 20% daripada semua). Imej ini mengandungi fail yang diperlukan untuk menjalankan aplikasi .hpkg, dipasang oleh sistem, dan selepas aplikasi selesai - dinyahlekapkan. (Mungkin pengurus fail boleh meletakkan fail .hpkg ke dalam imej aplikasi, secara automatik atau atas permintaan pengguna - baik, seperti apabila anda menyeret aplikasi ke direktori rangkaian atau pemacu luaran. Ia hanya sebuah lagu! Atau sebaliknya, puisi - haiku.) Sebaliknya, pengguna mungkin mahu memasang kandungan imej dalam bentuk fail.hpkg, selepas itu ia akan dikemas kini dan diproses dengan cara yang sama seolah-olah ia dipasang melalui HaikuDepot... Kita perlu sumbang saran).

Petikan dari mr. waddlesplash:

Menjalankan aplikasi daripada pemacu luaran atau direktori rangkaian berpotensi berguna. Dan menambah keupayaan untuk mengkonfigurasi lebih banyak "zon" untuk pkgman pasti akan menjadi ciri yang bagus.

Sistem sedemikian akan mengambil kesempatan daripada hpkg, direktori, dan imej aplikasi. Mereka baik secara individu, tetapi bersama-sama mereka akan menjadi kebal.

Kesimpulan

Haiku mempunyai infrastruktur yang menyediakan antara muka pengguna yang ringkas dan canggih untuk PC, dan jauh melangkaui apa yang biasanya disediakan untuk PC pada LinuxSistem pakej .hpkg — adalah salah satu contoh sedemikian, tetapi bahagian lain sistem juga dipenuhi dengan kecanggihan. Walau bagaimanapun, Haiku akan mendapat manfaat daripada sokongan yang betul untuk katalog dan imej aplikasi. Cara terbaik untuk melakukan ini adalah berbaloi untuk dibincangkan dengan orang yang mengetahui Haiku, falsafah dan seni binanya lebih baik daripada saya. Lagipun, saya baru sahaja menggunakan Haiku selama lebih kurang seminggu. Walau bagaimanapun, saya percaya perspektif baharu ini akan berguna kepada pereka, pembangun dan arkitek Haiku. Sekurang-kurangnya, saya gembira menjadi "rakan kongsi sparring" untuk mereka. Saya mempunyai lebih 10 tahun pengalaman praktikal bekerja dengan katalog aplikasi dan pakej imej untuk Linux, dan saya ingin mencari kegunaannya dalam Haiku, yang saya percaya ia sangat sesuai. Penyelesaian berpotensi yang saya cadangkan bukanlah satu-satunya untuk masalah yang telah saya huraikan, dan jika pasukan Haiku memutuskan untuk mencari penyelesaian lain yang lebih elegan, saya setuju. Pada prinsipnya, saya sudah memikirkan idea tentang cara membuat sistem ini hpkg lebih menakjubkan tanpa mengubah cara ia berfungsi. Ternyata pasukan Haiku telah lama memikirkan tentang pakej aplikasi apabila melaksanakan sistem pengurusan pakej, tetapi malangnya (saya fikir) idea itu menjadi "usang". Mungkin sudah tiba masanya untuk menghidupkannya semula?

Cubalah sendiri! Lagipun, projek Haiku menyediakan imej untuk but daripada DVD atau USB, yang dihasilkan setiap hari.
Adakah anda mempunyai sebarang soalan? Kami menjemput anda untuk berbahasa Rusia saluran telegram.

Gambaran keseluruhan ralat: Bagaimana untuk menembak kaki sendiri dalam C dan C++. Koleksi resipi Haiku OS

Dari pengarang terjemahan: ini adalah artikel kelapan dan terakhir dalam siri tentang Haiku.

Senarai artikel: Pertama Yang kedua Ketiga Keempat Kelima Keenam Ketujuh

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.