Sesuatu yang lain: Haiku app bundle?

TL; DR: Bolehkah Haiku mendapatkan sokongan yang sesuai untuk pakej aplikasi, seperti direktori aplikasi (seperti .app pada 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 pemahaman penuh, saya ialah pencipta dan pengarang AppImage, format pengedaran aplikasi Linux yang bertujuan untuk kesederhanaan Mac dan memberikan kawalan penuh kepada pengarang aplikasi dan pengguna akhir (jika anda ingin mengetahui lebih lanjut, lihat 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? Anda tidak perlu mencipta sesuatu sekarang, kerana sistem yang sudah wujud dalam Haiku berfungsi dengan hebat, tetapi percubaan khayalan adalah bagus. Ia juga menunjukkan kecanggihan Haiku, berbanding dengan persekitaran desktop Linux, di mana perkara sebegini amat sukar (saya berhak untuk berkata demikian: Saya telah bergelut dengan penyahpepijatan selama 10 tahun).

Pada Sistem Macintosh 1, setiap aplikasi ialah fail berasingan "diuruskan" dalam Finder. Menggunakan AppImage Saya cuba mencipta semula pengalaman pengguna yang sama di 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 daripada 10 tahun kewujudan, AppImage telah mendapat beberapa tarikan dan populariti: Linus Torvalds sendiri mengesahkannya secara terbuka, dan projek biasa (contohnya, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) telah menerima pakainya sebagai cara utama untuk mengedarkan binaan berterusan atau setiap malam, tidak mengganggu aplikasi pengguna yang dipasang atau dinyahpasang. Walau bagaimanapun, persekitaran dan pengedaran desktop Linux paling kerap masih berpegang kepada model pengedaran berasaskan penyelenggara tradisional dan/atau mempromosikan perniagaan perusahaan dan/atau program kejuruteraan mereka sendiri berdasarkan Flatpak (RedHat, Fedora, GNOME) dan Snappy (Kanonik, Ubuntu). Ia datang 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 aplikasi dan semua yang diperlukan untuk menjalankannya, yang dalam fikiran yang betul tidak boleh dianggap sebagai sebahagian daripada pemasangan lalai untuk setiap sistem sasaran yang agak baru-baru ini (pengedaran Linux). Ia juga mengandungi metadata, seperti nama aplikasi, ikon, jenis MIME, dsb., 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 kepelbagaian pengedaran Linux sedemikian, tiada apa-apa "dalam fikiran yang betul" boleh dipanggil "sebahagian daripada pemasangan lalai untuk setiap sistem sasaran baharu." Kami menangani isu 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 memuat turun. Percaya atau tidak, ini adalah halangan sebenar bagi sesetengah orang. Keperluan untuk menetapkan bit kebolehlaksanaan adalah menyusahkan walaupun untuk pengguna berpengalaman. Sebagai penyelesaian, kami mencadangkan memasang perkhidmatan kecil yang memantau fail AppImage dan menetapkan bit kebolehlaksanaannya. Dalam bentuk tulen, ia bukan penyelesaian terbaik, kerana ia tidak akan berfungsi di luar kotak. Pengedaran Linux tidak menyediakan perkhidmatan ini, oleh itu, pengguna mempunyai pengalaman buruk di luar kotak.
• Pengguna Linux mengharapkan aplikasi baharu mempunyai ikon dalam menu permulaan. Anda tidak boleh memberitahu sistem: "Lihat, ada aplikasi baharu, mari bekerja." 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 perkara di atas tidak mencukupi, masih tiada ikon AppImage dalam pengurus fail. Dunia Linux 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

Saya tertanya-tanya apa yang dunia Linux boleh belajar daripada Mac OS X untuk mengelak daripada mengacaukan penyepaduan sistem. Jika anda mempunyai masa dan berminat dengan ini, pastikan anda membaca apa yang Arnaud Gurdol, salah seorang jurutera Mac OS X yang pertama, berkata:

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-apa seperti infrastruktur ini pada desktop Linux, jadi kami mencari penyelesaian seputar batasan struktur dalam projek AppImage.

Adakah Haiku datang untuk menyelamatkan?

Dan satu lagi perkara: Platform Linux sebagai asas persekitaran desktop cenderung untuk menjadi sangat kurang spesifik sehingga banyak perkara yang agak mudah dalam sistem tindanan penuh yang konsisten adalah berpecah-belah dan kompleks dengan mengecewakan dalam Linux. Saya menumpukan keseluruhan laporan kepada isu yang berkaitan dengan platform Linux untuk persekitaran desktop (pembangun berpengetahuan mengesahkan bahawa segala-galanya akan kekal seperti ini untuk masa yang lama).

Laporan saya tentang masalah persekitaran desktop Linux pada tahun 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 cuba membina (terutamanya runtime.c dan perkhidmatan) komponennya (yang mungkin juga boleh dilakukan!), ini tidak akan memberikan banyak manfaat kepada Haiku. Kerana sebenarnya, kebanyakan masalah ini diselesaikan dalam Haiku dan adalah baik dari segi konsep. Haiku menyediakan betul-betul blok binaan infrastruktur sistem yang saya cari dalam persekitaran desktop Linux sejak sekian lama dan tidak percaya tiada di sana. Iaitu:

Percaya atau tidak, ini adalah sesuatu yang tidak dapat diatasi oleh ramai pengguna Linux. Pada 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 tongkat dan penyelesaian yang diperlukan oleh AppImage pada Linux menjadi tidak diperlukan pada Haiku, yang mempunyai kesederhanaan dan kecanggihan pada terasnya yang menjadikannya mengendalikan kebanyakan keperluan kita.

Adakah Haiku memerlukan pakej aplikasi?

Ini membawa kepada persoalan besar. Jika susunan magnitud lebih mudah untuk mencipta sistem seperti AppImage pada Haiku berbanding Linux, adakah patut dilakukan? Atau adakah Haiku, dengan sistem pakej hpkgnya, telah menghapuskan keperluan untuk membangunkan idea sedemikian dengan berkesan? Nah, untuk menjawab kita perlu melihat motivasi di sebalik kewujudan 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.

Berbilang versi AppImages berjalan sebelah menyebelah pada Linux yang sama

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 Linux. Atau mungkin saya mahu mengewangkan akses ke halaman ini, apa-apa boleh? 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

Di 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 rangka kerja yang menyediakan pengalaman pengguna yang ringkas dan canggih untuk PC, dan jauh melebihi apa yang biasanya disediakan untuk PC Linux. Sistem pakej .hpkg adalah salah satu contoh sedemikian, tetapi seluruh sistem juga dipenuhi dengan kecanggihan. Walau bagaimanapun, Haiku akan mendapat manfaat daripada direktori yang betul dan sokongan imej aplikasi. Cara terbaik untuk melakukan ini patut dibincangkan dengan orang yang mengetahui Haiku, falsafah dan seni binanya yang jauh lebih baik daripada saya. Lagipun, saya telah menggunakan Haiku selama lebih kurang seminggu. Namun begitu, saya percaya bahawa pereka, pembangun dan arkitek Haiku akan mendapat manfaat daripada perspektif baharu ini. Sekurang-kurangnya, saya akan gembira menjadi "pasangan sparing" mereka. Saya mempunyai lebih 10 tahun pengalaman praktikal dengan katalog dan himpunan aplikasi Linux, dan saya ingin mencari kegunaannya dalam Haiku, yang mana saya fikir ia sangat sesuai. Penyelesaian berpotensi yang saya cadangkan bukanlah satu-satunya penyelesaian yang betul untuk masalah yang telah saya huraikan, dan jika pasukan Haiku memutuskan untuk mencari penyelesaian lain yang lebih elegan, saya bersedia. Pada asasnya, saya sudah memikirkan idea bagaimana untuk membuat sistem 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.

Adakah masuk akal untuk mengalihkan sistem hpkg ke Linux?

• Ya

• Tiada

• Sudah dilaksanakan, saya akan menulis dalam komen

20 pengguna mengundi. 5 pengguna berpantang.

Sumber: www.habr.com