TL; DR: Bisakah Haiku mendapatkan dukungan yang tepat untuk paket aplikasi, seperti direktori aplikasi (seperti .app di Mac) dan/atau gambar aplikasi (Linux AppImage)? Saya pikir ini akan menjadi tambahan yang berharga dan lebih mudah diterapkan dengan benar dibandingkan sistem lain karena sebagian besar infrastruktur sudah ada.
Saya menemukan Haiku, sistem yang sangat bagus. Nah, karena saya sudah lama tertarik dengan direktori dan gambar aplikasi (terinspirasi dari kesederhanaan Macintosh), tidak mengherankan jika sebuah ide muncul di benak saya...
Untuk pemahaman penuh, saya adalah pencipta dan penulis AppImage, format distribusi aplikasi Linux yang bertujuan untuk kesederhanaan Mac dan memberikan kontrol penuh kepada pembuat aplikasi dan pengguna akhir (jika Anda ingin tahu lebih banyak, lihat ΠΈ ).
Bagaimana jika kita membuat AppImage untuk Haiku?
Mari kita berpikir sedikit, secara teoritis murni: apa yang perlu dilakukan untuk mendapatkannya , atau yang serupa, di Haiku? Tidak perlu membuat sesuatu saat ini, karena sistem yang sudah ada di Haiku bekerja dengan luar biasa, namun eksperimen imajiner akan menyenangkan. Ini juga menunjukkan kecanggihan Haiku, dibandingkan dengan lingkungan desktop Linux, di mana hal-hal seperti itu sangat sulit (saya berhak mengatakan demikian: Saya telah berjuang dengan debugging selama 10 tahun).
Pada Sistem Macintosh 1, setiap aplikasi merupakan file terpisah yang "dikelola" di Finder. Menggunakan AppImage Saya mencoba menciptakan kembali pengalaman pengguna yang sama di Linux.
Pertama, apa itu AppImage? Ini adalah sistem untuk merilis aplikasi pihak ketiga (misalnya, ), memungkinkan aplikasi untuk dirilis kapan dan bagaimana mereka inginkan: tidak perlu mengetahui secara spesifik berbagai distribusi, membuat kebijakan atau membangun infrastruktur, tidak diperlukan dukungan pengelola, dan mereka tidak memberi tahu pengguna apa (yang tidak) dapat mereka instal di komputer mereka. AppImage harus dipahami sebagai sesuatu yang mirip dengan paket Mac dalam format .app di dalam gambar disk .dmg. Perbedaan utamanya adalah aplikasi tidak disalin, namun tetap berada di dalam AppImage selamanya, sama seperti paket Haiku .hpkg dipasang, dan tidak pernah dipasang seperti biasanya.
Selama lebih dari 10 tahun keberadaannya, AppImage telah mendapatkan daya tarik dan popularitas: Linus Torvalds sendiri secara terbuka mendukungnya, dan proyek-proyek umum (misalnya, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) telah mengadopsinya sebagai cara utama untuk mendistribusikan pembangunan berkelanjutan atau setiap malam, tidak mengganggu aplikasi pengguna yang diinstal atau dihapus instalasinya. Namun, lingkungan desktop dan distribusi Linux seringkali masih berpegang teguh pada model distribusi tradisional berbasis pengelola terpusat dan/atau mempromosikan bisnis perusahaan mereka sendiri dan/atau program rekayasa berdasarkan (RedHat, Fedora, GNOME) dan (Kanonik, Ubuntu). Itu datang .
Bagaimana semuanya bekerja
- Setiap AppImage berisi 2 bagian: ELF klik dua kali kecil (disebut.
runtime.c), diikuti dengan gambar sistem file .
- Sistem file SquashFS berisi payload aplikasi dan semua yang diperlukan untuk menjalankannya, yang tidak dapat dianggap sebagai bagian dari instalasi default untuk setiap sistem target terbaru (distribusi Linux). Ini juga berisi metadata, seperti nama aplikasi, ikon, jenis MIME, dll., dll.
- Ketika dijalankan oleh pengguna, runtime menggunakan FUSE dan squashfuse untuk memasang sistem file, dan kemudian menangani menjalankan beberapa titik masuk (alias AppRun) di dalam AppImage yang dipasang.
Sistem file dilepas setelah proses selesai.
Segalanya tampak sederhana.
Dan hal-hal ini memperumit segalanya:
- Dengan begitu beragamnya distribusi Linux, tidak ada hal βberpikiran sehatβ yang dapat disebut sebagai βbagian dari instalasi default untuk setiap sistem target baru.β Kami mengatasi masalah ini dengan membangun , memungkinkan Anda menentukan apa yang akan dikemas dalam AppImage dan apa yang perlu dibawa ke tempat lain. Pada saat yang sama, terkadang kita meleset, meskipun faktanya, secara umum, semuanya berjalan dengan baik. Untuk alasan ini, kami menyarankan pembuat paket menguji AppImages pada semua sistem target (distribusi).
- Muatan aplikasi harus dapat dipindahkan ke seluruh sistem file. Sayangnya, banyak aplikasi memiliki jalur absolut yang dikodekan secara keras, misalnya, ke sumber daya
/usr/share. Ini perlu diperbaiki. Selain itu, Anda harus mengeksporLD_LIBRARY_PATH, atau perbaikirpathsehingga pemuat dapat menemukan perpustakaan terkait. Metode pertama memiliki kekurangan (yang dapat diatasi dengan cara yang rumit), dan metode kedua cukup rumit. - Jebakan UX terbesar bagi pengguna adalah hal itu File AppImage setelah diunduh. Percaya atau tidak, ini merupakan hambatan nyata bagi sebagian orang. Kebutuhan untuk mengatur bit eksekusi tidak praktis bahkan untuk pengguna berpengalaman. Sebagai solusinya, kami menyarankan untuk menginstal layanan kecil yang memantau file AppImage dan menyetel bit eksekusinya. Dalam bentuknya yang murni, ini bukanlah solusi terbaik, karena tidak akan berfungsi begitu saja. Distribusi Linux tidak menyediakan layanan ini, oleh karena itu, pengguna langsung mendapatkan pengalaman buruk.
- Pengguna Linux mengharapkan aplikasi baru memiliki ikon di menu startup. Anda tidak bisa memberi tahu sistem: βLihat, ada lamaran baru, ayo bekerja.β Sebaliknya, menurut spesifikasi XDG, Anda perlu menyalin file tersebut
.desktopke tempat yang tepat di/usruntuk instalasi seluruh sistem, atau di$HOMEuntuk individu. Ikon dengan ukuran tertentu, menurut spesifikasi XDG, perlu ditempatkan di tempat tertentuusrΠΈΠ»ΠΈ$HOME, lalu jalankan perintah di lingkungan kerja untuk memperbarui cache ikon, atau berharap manajer lingkungan kerja akan mengetahuinya dan secara otomatis mendeteksi semuanya. Sama dengan tipe MIME. Sebagai solusinya, diusulkan untuk menggunakan layanan yang sama, yang selain mengatur tanda eksekusi, akan, jika ada ikon, dll. di AppImage, salin dari AppImage ke tempat yang tepat menurut XDG. Ketika dihapus atau dipindahkan, layanan diharapkan dapat menghapus semuanya. Tentu saja, terdapat perbedaan dalam perilaku setiap lingkungan kerja, dalam format file grafik, ukurannya, lokasi penyimpanan dan metode untuk memperbarui cache, yang menimbulkan masalah. Singkatnya, metode ini adalah penopang. - Jika cara di atas belum cukup, masih belum ada ikon AppImage di pengelola file. Dunia Linux belum memutuskan untuk mengimplementasikan elficon (walaupun ΠΈ ), sehingga tidak mungkin menyematkan ikon secara langsung ke dalam aplikasi. Jadi ternyata aplikasi yang ada di file manager tidak punya icon sendiri (tidak ada bedanya, AppImage atau yang lainnya), hanya ada di start menu. Sebagai solusinya, kami menggunakan thumbnail, sebuah mekanisme yang awalnya dirancang untuk memungkinkan pengelola desktop menampilkan gambar pratinjau thumbnail dari file grafik sebagai ikonnya. Akibatnya, layanan untuk mengatur bit eksekusi juga berfungsi sebagai "miniaturizer", membuat dan menulis thumbnail ikon ke lokasi yang sesuai
/usrΠΈ$HOME. Layanan ini juga melakukan pembersihan jika AppImage dihapus atau dipindahkan. Karena kenyataan bahwa setiap pengelola desktop berperilaku sedikit berbeda, misalnya, dalam format apa ia menerima ikon, dalam ukuran atau tempat apa, ini semua sangat menyakitkan. - Aplikasi hanya mogok saat dijalankan jika terjadi kesalahan (misalnya, ada perpustakaan yang bukan bagian dari sistem dasar dan tidak disediakan di AppImage), dan tidak ada yang memberi tahu pengguna di GUI apa yang sebenarnya terjadi. Kami mulai menyiasatinya dengan menggunakan di desktop, yang berarti kita perlu menangkap kesalahan dari baris perintah, mengubahnya menjadi pesan yang dapat dimengerti pengguna, yang kemudian perlu ditampilkan di desktop. Dan tentu saja, setiap lingkungan desktop menanganinya sedikit berbeda.
- Saat ini (September 2019 - catatan penerjemah) Saya belum menemukan cara sederhana untuk memberi tahu sistem bahwa file tersebut
1.pngharus dibuka menggunakan Krita, dan2.png- menggunakan GIMP.
Lokasi penyimpanan untuk spesifikasi lintas desktop yang digunakan di , ΠΈ adalah freedesktop.org
Mencapai tingkat kecanggihan yang tertanam dalam lingkungan kerja Haiku sulit, bahkan tidak mungkin, karena spesifikasinya untuk lintas desktop, serta implementasi pengelola desktop berdasarkan spesifikasi ini. Sebagai contoh, kita dapat mengutip satu ikon Firefox di seluruh sistem: rupanya, pembuat XDG bahkan tidak berpikir bahwa pengguna dapat menginstal beberapa versi aplikasi yang sama.
Ikon untuk berbagai versi Firefox
Saya bertanya-tanya apa yang bisa dipelajari dunia Linux dari Mac OS X untuk menghindari mengacaukan integrasi sistem. Jika Anda punya waktu dan tertarik dengan hal ini, pastikan untuk membaca apa yang dikatakan Arnaud Gurdol, salah satu insinyur Mac OS X pertama:
Kami ingin menginstal aplikasi semudah menyeret ikon aplikasi dari suatu tempat (server, drive eksternal) ke drive komputer Anda. Untuk melakukan ini, paket aplikasi menyimpan semua informasi, termasuk ikon, versi, jenis file yang sedang diproses, jenis skema URL yang perlu diketahui sistem untuk memproses aplikasi. Ini juga mencakup informasi untuk 'penyimpanan pusat' di database Layanan Ikon dan Layanan Peluncuran. Untuk mendukung kinerja, aplikasi 'ditemukan' di beberapa tempat 'terkenal': direktori Aplikasi sistem dan pengguna, dan beberapa lainnya secara otomatis jika pengguna menavigasi ke Finder di direktori yang berisi aplikasi tersebut. Dalam praktiknya, hal ini berhasil dengan sangat baik.
Apple WWDC 2000 sesi 144 - Mac OS X: mengemas aplikasi dan mencetak dokumen.
Tidak ada infrastruktur seperti ini di desktop Linux, jadi kami mencari solusi untuk mengatasi keterbatasan struktural dalam proyek AppImage.
Apakah Haiku datang untuk menyelamatkan?
Satu hal lagi: Platform Linux sebagai basis lingkungan desktop cenderung terlalu tidak ditentukan sehingga banyak hal yang cukup sederhana dalam sistem full-stack yang koheren menjadi terfragmentasi dan rumit di Linux. Saya mengabdikan seluruh laporan untuk masalah yang terkait dengan platform Linux untuk lingkungan desktop (pengembang berpengetahuan telah mengkonfirmasi bahwa semuanya akan tetap seperti ini untuk waktu yang sangat lama).
Laporan saya tentang masalah lingkungan desktop Linux pada tahun 2018
Bahkan Linus Torvalds mengakui bahwa fragmentasi adalah penyebab kegagalan ide ruang kerja.
Senang melihat Haiku!
Haiku membuat segalanya menjadi sangat sederhana
Meskipun pendekatan naif untuk "mem-porting" AppImage ke Haiku adalah dengan mencoba membangun (terutama runtime.c dan melayani) komponen-komponennya (yang bahkan mungkin dilakukan!), hal ini tidak akan memberikan banyak manfaat bagi Haiku. Karena kenyataannya, sebagian besar masalah ini diselesaikan di Haiku dan secara konseptual masuk akal. Haiku menyediakan blok bangunan infrastruktur sistem yang sudah lama saya cari di lingkungan desktop Linux dan saya tidak percaya mereka tidak ada di sana. Yaitu:
Percaya atau tidak, ini adalah sesuatu yang tidak dapat diatasi oleh banyak pengguna Linux. Di Haiku semuanya dilakukan secara otomatis!
- File ELF yang tidak memiliki bit eksekusi akan mendapatkannya secara otomatis ketika diklik dua kali di pengelola file.
- Aplikasi dapat memiliki sumber daya bawaan, seperti ikon, yang ditampilkan di pengelola file. Tidak perlu menyalin banyak gambar ke direktori khusus dengan ikon, dan oleh karena itu tidak perlu membersihkannya setelah menghapus atau memindahkan aplikasi.
- Ada database untuk menghubungkan aplikasi dengan dokumen, tidak perlu menyalin file apa pun untuk ini.
- Di direktori lib/ di sebelah file yang dapat dieksekusi, perpustakaan dicari secara default.
- Tidak ada banyak distribusi dan lingkungan desktop; apa pun yang berfungsi, berfungsi di mana saja.
- Tidak ada modul terpisah untuk dijalankan yang berbeda dari direktori Aplikasi.
- Aplikasi tidak memiliki jalur absolut bawaan ke sumber dayanya; aplikasi memiliki fungsi khusus untuk menentukan lokasi saat runtime.
- Gagasan gambar sistem file terkompresi telah diperkenalkan: ini adalah paket hpkg apa pun. Semuanya di-mount oleh kernel.
- Setiap file dibuka oleh aplikasi yang membuatnya, kecuali Anda secara eksplisit menentukan sebaliknya. Keren sekali ini!
Dua file png. Perhatikan ikon berbeda yang menunjukkan bahwa ikon tersebut akan dibuka oleh aplikasi berbeda ketika diklik dua kali. Perhatikan juga menu tarik-turun "Buka dengan:" di mana pengguna dapat memilih aplikasi individual. Sederhana sekali!
Sepertinya banyak kruk dan solusi yang diperlukan oleh AppImage di Linux menjadi tidak diperlukan di Haiku, yang memiliki kesederhanaan dan kecanggihan pada intinya yang membuatnya menangani sebagian besar kebutuhan kita.
Apakah Haiku memerlukan paket aplikasi?
Hal ini menimbulkan pertanyaan besar. Jika membuat sistem seperti AppImage di Haiku jauh lebih mudah daripada di Linux, apakah hal itu layak dilakukan? Atau apakah Haiku, dengan sistem paket hpkgnya, secara efektif menghilangkan kebutuhan untuk mengembangkan ide semacam itu? Nah, untuk menjawabnya kita perlu melihat motivasi di balik keberadaan AppImages.
Perspektif pengguna
Mari kita lihat pengguna akhir kita:
- Saya ingin menginstal aplikasi tanpa meminta kata sandi administrator (root). Tidak ada konsep administrator di Haiku, pengguna memiliki kendali penuh karena ini adalah sistem pribadi! (Pada prinsipnya, Anda dapat membayangkan ini dalam mode multipemain, saya harap pengembang membuatnya tetap sederhana)
- Saya ingin mendapatkan aplikasi versi terbaru dan terhebat, tanpa menunggu aplikasi tersebut muncul di distribusi saya (paling sering ini berarti βtidak pernahβ, setidaknya kecuali saya memperbarui seluruh sistem operasi). Di Haiku ini "diselesaikan" dengan rilis mengambang. Artinya, dimungkinkan untuk mendapatkan versi aplikasi terbaru dan terhebat, namun untuk melakukan hal ini Anda perlu terus memperbarui seluruh sistem, yang secara efektif mengubahnya menjadi βtarget bergerakβ.
- Saya ingin beberapa versi dari aplikasi yang sama secara berdampingan, karena tidak ada cara untuk mengetahui apa yang rusak di versi terbaru, atau, katakanlah, saya, sebagai pengembang web, perlu menguji pekerjaan saya di bawah versi browser yang berbeda. Haiku memecahkan masalah pertama, tapi bukan masalah kedua. Pembaruan dibatalkan, tetapi hanya untuk keseluruhan sistem; tidak mungkin (sejauh yang saya tahu) untuk menjalankan, misalnya, beberapa versi WebPositive atau LibreOffice secara bersamaan.
Salah satu pengembang menulis:
Pada dasarnya alasannya adalah ini: kasus penggunaan sangat jarang sehingga pengoptimalannya tidak masuk akal; memperlakukannya sebagai kasus khusus di HaikuPorts tampaknya lebih dari cukup.
- Saya perlu menyimpan aplikasi di tempat yang saya suka, bukan di drive startup saya. Saya sering kehabisan ruang disk, jadi saya perlu menghubungkan drive eksternal atau direktori jaringan untuk menyimpan aplikasi (semua versi yang telah saya unduh). Jika saya menghubungkan drive seperti itu, saya memerlukan aplikasi untuk diluncurkan dengan mengklik dua kali. Haiku menyimpan paket versi lama, tetapi saya tidak tahu cara memindahkannya ke drive eksternal, atau cara meluncurkan aplikasi dari sana nanti.
Komentar pengembang:
Secara teknis, ini sudah dimungkinkan dengan perintah mount. Tentu saja, kami akan membuat GUI untuk ini segera setelah kami memiliki cukup banyak pengguna yang berminat.
- Saya tidak memerlukan jutaan file yang tersebar di seluruh sistem file yang tidak dapat saya kelola sendiri secara manual. Saya ingin satu file per aplikasi yang dapat saya unduh, pindahkan, hapus dengan mudah. Di Haiku masalah ini diselesaikan dengan menggunakan paket
.hpkg, yang mentransfer, misalnya python, dari ribuan file menjadi satu. Tapi kalau misalnya ada Scribus yang menggunakan python, maka saya harus berurusan dengan setidaknya dua file. Dan saya harus berhati-hati untuk menjaga versinya tetap berfungsi satu sama lain.
Beberapa versi AppImages berjalan berdampingan di Linux yang sama
Perspektif pengembang aplikasi
Mari kita lihat dari sudut pandang pengembang aplikasi:
- Saya ingin mengontrol seluruh pengalaman pengguna. Saya tidak ingin bergantung pada sistem operasi untuk memberi tahu saya kapan dan bagaimana saya harus merilis aplikasi. Haiku mengizinkan pengembang untuk bekerja dengan repositori hpkg mereka sendiri, namun ini berarti pengguna harus mengaturnya secara manual, sehingga ide tersebut "kurang menarik".
- Saya memiliki halaman unduh di situs web tempat saya mendistribusikan
.exeuntuk Windows,.dmguntuk Mac dan.AppImageuntuk Linux. Atau mungkin saya ingin memonetisasi akses ke halaman ini, apa saja bisa? Apa yang harus saya taruh di sana untuk Haiku? Filenya sudah cukup.hpkgdengan ketergantungan hanya dari HaikuPorts - Perangkat lunak saya memerlukan versi spesifik perangkat lunak lain. Misalnya, diketahui bahwa Krita memerlukan versi Qt yang dipatch, atau Qt yang disesuaikan dengan versi Krita tertentu, setidaknya hingga patch tersebut dimasukkan kembali ke Qt. Anda dapat mengemas Qt Anda sendiri untuk aplikasi Anda dalam sebuah paket
.hpkg, tapi kemungkinan besar hal ini tidak diterima.
Halaman pengunduhan aplikasi biasa. Apa yang harus saya posting di sini untuk Haiku?
Akan dibundel (ada sebagai direktori aplikasi seperti AppDir atau .app dalam gaya Apple) dan/atau gambar (dalam bentuk AppImages yang banyak dimodifikasi atau .dmg dari Apple) aplikasi tambahan yang berguna untuk lingkungan desktop Haiku? Atau akankah hal ini melemahkan keseluruhan gambaran dan menyebabkan fragmentasi, sehingga menambah kompleksitas? Saya bingung: di satu sisi, keindahan dan kecanggihan Haiku didasarkan pada kenyataan bahwa biasanya hanya ada satu cara untuk melakukan sesuatu, bukan banyak cara. Di sisi lain, sebagian besar infrastruktur untuk katalog dan/atau rangkaian aplikasi telah ada, sehingga sistem memerlukan beberapa persen sisanya agar dapat berfungsi dengan baik.
Menurut pengembang
Di Linux mereka (katalog dan kit aplikasi, - kira-kira. Penerjemah) kemungkinan besar merupakan solusi teknis untuk masalah sistemik. Di Haiku kami lebih suka menyelesaikan masalah sistem saja.
Bagaimana menurutmu?
Sebelum Anda menjawab...
Tunggu, mari kita lakukan pemeriksaan realitas secara singkat: faktanya direktori aplikasi - sudah menjadi bagian dari Haiku:
Direktori aplikasi sudah ada di Haiku, namun belum didukung di pengelola file
Hanya saja dukungannya tidak sebaik, katakanlah, Macintosh Finder. Betapa kerennya jika direktori QtCreator memiliki nama dan ikon "QtCreator" di pojok kiri atas, meluncurkan aplikasi ketika diklik dua kali?
Beberapa saat sebelumnya saya sudah :
Apakah Anda yakin dapat menjalankan aplikasi berusia satu dekade saat ini ketika semua toko aplikasi dan repositori distribusi sudah melupakan aplikasi tersebut dan ketergantungannya? Apakah Anda yakin bahwa Anda masih dapat mengakses pekerjaan Anda saat ini di masa depan?
Apakah sudah ada jawaban dari Haiku, atau katalog dan application bundle bisa membantu disini? Saya pikir mereka bisa.
Menurut Pak. percikan waddle:
Ya, kami memiliki jawaban atas pertanyaan tersebut: kami hanya akan mendukung aplikasi ini selama diperlukan hingga seseorang dapat membaca format filenya dengan cara yang benar atau menyediakan fungsionalitas satu-ke-satu. Komitmen kami untuk mendukung aplikasi BeOS R5 di Haiku adalah buktinya...
Ini pasti!
Tindakan apa yang harus diambil Haiku?
Saya dapat membayangkan hidup berdampingan secara damai antara hpkg, direktori, dan gambar aplikasi:
- Penggunaan perangkat lunak sistem
.hpkg - Untuk perangkat lunak yang paling sering digunakan (terutama yang perlu menjadwalkan rilis bergulir), gunakan
.hpkg(sekitar 80% dari semua kasus) - Beberapa diinstal melalui
.hpkg, aplikasi akan mendapat manfaat dari perpindahan ke infrastruktur direktori aplikasi (misalnya QtCreator): aplikasi akan didistribusikan sebagai.hpkg, seperti sebelumnya.
Tn. waddlesplash menulis:
Jika yang Anda perlukan hanyalah melihat aplikasi
/system/apps, sebagai gantinya kita harus membuat direktori di Deskbar lebih mudah dikelola oleh pengguna/system/appstidak dimaksudkan untuk dibuka dan dilihat secara rutin oleh pengguna (tidak seperti MacOS). Untuk situasi seperti itu, Haiku memiliki paradigma yang berbeda, namun opsi ini, secara teori, dapat diterima.
- Haiku menerima infrastruktur untuk menjalankan gambar aplikasi, setiap malam, berkelanjutan, dan menguji pembuatan perangkat lunak, serta untuk kasus ketika pengguna ingin "membekukannya tepat waktu", untuk perangkat lunak pribadi dan internal, dan kasus penggunaan khusus lainnya (sekitar 20% dari semua). Gambar-gambar ini berisi file yang diperlukan untuk menjalankan aplikasi
.hpkg, dipasang oleh sistem, dan setelah aplikasi selesai - dilepas. (Mungkin pengelola file dapat menaruh file.hpkgke dalam gambar aplikasi, secara otomatis atau atas permintaan pengguna - seperti saat Anda menyeret aplikasi ke direktori jaringan atau drive eksternal. Itu hanya sebuah lagu! Atau lebih tepatnya, puisi - haiku.) Di sisi lain, pengguna mungkin ingin menginstal konten gambar dalam bentuk file.hpkg, setelah itu akan diperbarui dan diproses dengan cara yang sama seperti jika diinstal melalui HaikuDepot... Kita perlu bertukar pikiran).
Kutipan dari Pak. percikan waddle:
Menjalankan aplikasi dari drive eksternal atau direktori jaringan berpotensi bermanfaat. Dan menambahkan kemampuan untuk mengonfigurasi lebih banyak "zona" untuk pkgman pasti akan menjadi fitur yang bagus.
Sistem seperti itu akan memanfaatkan hpkg, direktori, dan gambar aplikasi. Mereka bagus secara individu, tapi bersama-sama mereka akan menjadi tak terkalahkan.
Kesimpulan
Haiku memiliki kerangka kerja yang memberikan pengalaman pengguna yang sederhana dan canggih untuk PC, dan jauh melampaui apa yang biasanya disediakan untuk PC Linux. Sistem paket .hpkg adalah salah satu contohnya, namun sistem lainnya juga dilengkapi dengan kecanggihan. Namun, Haiku akan mendapat manfaat dari dukungan direktori dan gambar aplikasi yang tepat. Cara terbaik untuk melakukan hal ini adalah dengan berdiskusi dengan orang-orang yang mengenal Haiku, filosofi dan arsitekturnya jauh lebih baik daripada saya. Lagipula, saya sudah menggunakan Haiku selama lebih dari seminggu. Meskipun demikian, saya percaya bahwa para desainer, pengembang, dan arsitek Haiku akan mendapatkan manfaat dari perspektif baru ini. Paling tidak, saya akan senang menjadi βsparring partnerβ mereka. Saya memiliki lebih dari 10 tahun pengalaman dengan katalog dan bundel aplikasi Linux, dan saya ingin menemukan kegunaannya di Haiku, yang menurut saya sangat cocok. Solusi potensial yang saya usulkan bukanlah satu-satunya solusi yang tepat untuk masalah yang telah saya jelaskan, dan jika tim Haiku memutuskan untuk mencari solusi lain yang lebih elegan, saya mendukungnya. Pada dasarnya saya sudah memikirkan ide bagaimana membuat sebuah sistem hpkg bahkan lebih menakjubkan tanpa mengubah cara kerjanya. Ternyata tim Haiku sudah lama memikirkan tentang application bundle ketika mengimplementasikan sistem manajemen paket, namun sayangnya (menurut saya) ide tersebut menjadi "usang". Mungkin sudah waktunya untuk menghidupkannya kembali?
Cobalah sendiri! Bagaimanapun, proyek Haiku menyediakan gambar untuk boot dari DVD atau USB, yang dihasilkan .
Apakah Anda memiliki pertanyaan? Kami mengundang Anda ke berbahasa Rusia .
Ikhtisar kesalahan:
Dari terjemahan: ini adalah artikel kedelapan dan terakhir dalam seri tentang Haiku.
Daftar artikel:
Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. , silakan.
Apakah masuk akal untuk mem-porting sistem hpkg ke Linux?
-
Ya
-
Tidak
-
Sudah diterapkan, saya akan menulis di komentar
20 pengguna memilih. 5 pengguna abstain.
Sumber: www.habr.com