TL; DR : Bisakah Haiku mendapatkan dukungan yang tepat untuk paket aplikasi, seperti direktori aplikasi (seperti .app pada Mac) dan / atau gambar aplikasi (Linux AppImage )? Tampaknya bagi saya bahwa ini akan menjadi tambahan yang layak, yang lebih mudah diimplementasikan dengan benar daripada di sistem lain, karena sebagian besar infrastruktur sudah ada di sana.
Seminggu yang lalu, saya menemukan Haiku, sistem yang baik secara tak terduga. Yah, karena saya telah lama tertarik pada katalog dan gambar aplikasi (terinspirasi oleh kesederhanaan Macintosh), tidak mengherankan bahwa sebuah ide muncul di benak saya ...
Untuk pemahaman lengkap: Saya adalah pencipta dan penulis AppImage, format distribusi aplikasi Linux yang ditujukan untuk kesederhanaan Mac dan memberikan kontrol penuh kepada penulis aplikasi dan pengguna akhir (ingin tahu lebih banyak - lihat wiki dan dokumentasi ).
Bagaimana jika kita melakukan AppImage untuk Haiku?
Mari kita berpikir sedikit, murni secara teoritis: apa yang perlu dilakukan untuk mendapatkan AppImage , atau yang serupa, di Haiku? Tidak perlu membuat sesuatu sekarang, karena sistem yang sudah ada di Haiku bekerja dengan luar biasa, tetapi eksperimen imajiner akan berubah menjadi baik. Dia juga menunjukkan kecanggihan Haiku, dibandingkan dengan lingkungan desktop Linux di mana hal-hal seperti itu sangat sulit (saya punya hak untuk mengatakannya: Saya sudah melakukan debugging selama 10 tahun sekarang).
Pada Macintosh System 1, setiap aplikasi adalah file terpisah yang "dikelola" di Finder. Menggunakan AppImage, saya mencoba membuat ulang pengalaman pengguna yang sama di Linux.
Pertama-tama, apa itu AppImage? Ini adalah sistem untuk merilis aplikasi pihak ketiga (misalnya, Ultimaker Cura ) yang memungkinkan Anda untuk merilis aplikasi kapan dan bagaimana mereka berburu: Anda tidak perlu mengetahui fitur dari berbagai distribusi, membangun kebijakan atau membangun infrastruktur, mereka tidak memerlukan dukungan dari pengelola, dan mereka tidak memberi tahu pengguna apa yang (tidak) dapat diinstal pada komputer. AppImage harus dipahami sebagai sesuatu seperti paket untuk Mac dalam format .app di dalam disk image .dmg . Perbedaan utama adalah bahwa aplikasi tidak disalin, tetapi tetap di dalam AppImage selalu, seperti paket Haiku .hpkg diinstal, dan tidak pernah diinstal dalam arti biasa.
Selama lebih dari 10 tahun keberadaannya, AppImage memperoleh daya tarik dan popularitas: Linus Torvalds sendiri secara terbuka menyetujuinya, dan proyek-proyek yang tersebar luas (misalnya, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) menganggapnya sebagai cara utama untuk mendistribusikan rakitan yang terus menerus atau malam, bukan mengganggu aplikasi pengguna yang diinstal atau tidak diinstal. Namun, desktop dan distribusi Linux paling sering masih berpegang pada model distribusi tradisional yang terpusat berdasarkan pada pengelola dan / atau mempromosikan bisnis perusahaan mereka sendiri dan / atau program rekayasa berdasarkan Flatpak (RedHat, Fedora, GNOME) dan Snappy (Canonical, Ubuntu) . Datang ke lucu .
Bagaimana cara kerjanya
- Setiap AppImage berisi 2 bagian: ELF kecil yang dapat dieksekusi klik ganda (disebut.
runtime.c ), diikuti oleh gambar sistem file SquashFS .
- Sistem file SquashFS berisi muatan dalam bentuk aplikasi dan semua yang Anda perlukan untuk menjalankannya, yang dalam pikiran Anda tidak dapat dianggap sebagai bagian dari instalasi default untuk setiap sistem target yang cukup baru (distribusi Linux). Ini juga berisi metadata, misalnya, nama aplikasi, ikon, tipe MIME, dll., Dll.
- Ketika diluncurkan oleh pengguna, runtime menggunakan FUSE dan squashfuse untuk me-mount sistem file, setelah itu memproses peluncuran beberapa titik masuk (yang disebut AppRun) di dalam AppImage yang terpasang.
Sistem file dilepas setelah proses selesai.
Tampaknya semuanya sederhana.
Dan hal-hal ini menyulitkan:
- dengan berbagai distribusi Linux seperti itu, tidak ada yang "dalam pikiran mereka" yang dapat Anda sebut "bagian dari instalasi default untuk setiap sistem target baru". Kami menghindari masalah ini dengan mengumpulkan excludelist , yang memungkinkan kami untuk menentukan apa yang akan dikemas dalam AppImage dan apa yang perlu dibawa ke tempat lain. Pada saat yang sama, kadang-kadang kita kehilangan, meskipun pada kenyataannya, secara umum, semuanya bekerja dengan baik. Karena alasan ini, kami menyarankan agar pembuat paket memeriksa AppImages pada semua sistem target (distribusi).
- Aplikasi dalam bentuk payload harus berkeliaran di sekitar sistem file. Sayangnya, dalam banyak aplikasi jalur absolut ke, misalnya, sumber daya di
/usr/share hard-coded. Ini perlu diperbaiki, entah bagaimana. Selain itu, Anda harus mengekspor LD_LIBRARY_PATH , atau memperbaiki rpath agar pemuat dapat menemukan perpustakaan terkait. Metode pertama memiliki kelemahan (yang dikelola dengan cara yang kompleks), dan yang kedua hanya rumit. - Jebakan UX terbesar bagi pengguna adalah mengatur bit yang dapat dieksekusi ke file AppImage setelah mengunduh. Percaya atau tidak, bagi sebagian orang itu penghalang nyata. Kebutuhan untuk mengatur bit yang dapat dieksekusi adalah rumit bahkan untuk pengguna tingkat lanjut. Sebagai solusinya, kami mengusulkan untuk menginstal layanan kecil yang memonitor file AppImage dan menetapkan bit yang dapat dieksekusi untuk mereka. Dalam bentuknya yang murni, bukan solusi terbaik, karena tidak akan berfungsi di luar kotak. Distribusi Linux tidak memberikan layanan ini, oleh karena itu, di luar kotak pengguna tidak melakukannya dengan baik.
- Pengguna Linux mengharapkan aplikasi baru untuk memiliki ikon di menu peluncuran. Anda tidak dapat memberi tahu sistem: "Lihat, ada aplikasi baru, mari bekerja." Sebaliknya, sesuai dengan spesifikasi XDG, Anda perlu menyalin file
.desktop ke lokasi yang diinginkan di /usr untuk pemasangan di seluruh sistem, atau di $HOME untuk instalasi individu. Ikon ukuran tertentu, sesuai spesifikasi XDG, Anda harus meletakkannya di tempat-tempat tertentu di usr atau $HOME , dan kemudian menjalankan perintah di lingkungan kerja untuk memperbarui cache ikon, atau berharap bahwa manajer lingkungan kerja akan mengetahuinya dan secara otomatis mendeteksi semuanya. Demikian pula dengan jenis MIME. Sebagai solusi, ia menawarkan Untuk menggunakan layanan yang sama, yang, selain mengatur flag eksekusi, akan, jika ada ikon, dll di AppImage, menyalinnya dari AppImage ke tempat yang benar sesuai dengan XDG, diasumsikan bahwa layanan akan menghapus segalanya ketika menghapus atau memindahkannya. Tentu saja, ada perbedaan perilaku untuk masing-masing lingkungan kerja, dalam format file grafik, ukurannya, lokasi penyimpanan dan cara-cara untuk memperbarui cache, yang menciptakan masalah. Singkatnya, metode ini adalah penopang. - Jika di atas tidak cukup, tidak ada ikon AppImage di manajer file. Di dunia Linux, mereka masih belum memutuskan untuk mengimplementasikan elficon (terlepas dari diskusi dan implementasi ), sehingga tidak mungkin untuk menanamkan ikon langsung ke dalam aplikasi. Jadi ternyata aplikasi dalam file manager tidak memiliki ikon sendiri (tidak ada perbedaan, AppImage atau yang lainnya), mereka hanya ada di menu mulai. Sebagai solusinya, kami menggunakan thumbnail - mekanisme yang awalnya dikembangkan sehingga manajer desktop dapat menampilkan thumbnail untuk melihat pratinjau file grafik sebagai ikon mereka. Oleh karena itu, layanan untuk mengatur bit yang dapat dieksekusi juga berfungsi sebagai "miniaturizer", membuat dan merekam thumbnail ikon di tempat
/usr sesuai dan $HOME . Layanan ini juga melakukan pengupasan jika AppImage dihapus atau dipindahkan. Karena kenyataan bahwa setiap manajer desktop berperilaku sedikit berbeda, misalnya, dalam format apa ia menerima ikon, dalam ukuran atau tempat apa, ini semua sangat menyakitkan. - Aplikasi hanya macet saat runtime jika kesalahan terjadi (misalnya, ada perpustakaan yang bukan bagian dari sistem dasar dan tidak disediakan di AppImage), dan tidak ada yang memberi tahu pengguna dalam GUI apa sebenarnya yang terjadi. Kami mulai mengatasi ini menggunakan pemberitahuan di desktop, yang berarti bahwa kami perlu menangkap kesalahan dari baris perintah, mengubahnya menjadi pesan yang dapat dimengerti pengguna, yang kemudian masih perlu ditampilkan di desktop. Dan tentu saja, setiap lingkungan kerja memperlakukan mereka sedikit berbeda.
- Saat ini (September 2019, kira-kira Penerjemah), saya belum menemukan cara sederhana untuk memberi tahu sistem bahwa file
1.png dibuka menggunakan Krita, dan 2.png - menggunakan GIMP.
Lokasi penyimpanan untuk spesifikasi lintas-desktop yang digunakan oleh GNOME , KDE, dan Xfce adalah freedesktop.org
Mencapai tingkat kecanggihan yang terjalin dalam lingkungan kerja Haiku adalah sulit, jika bukan tidak mungkin, karena spesifikasi XDG dari freedesktop.org untuk lintas-desktop, serta implementasi manajer desktop berdasarkan spesifikasi ini. Sebagai contoh, kita dapat mengutip satu ikon Firefox di seluruh sistem: tampaknya, para penulis XDG bahkan tidak berpikir bahwa pengguna dapat memiliki beberapa versi aplikasi yang sama.
Ikon dari berbagai versi Firefox
Saya bertanya-tanya apa yang bisa dipelajari dunia Linux dari Mac OS X, agar tidak mengacaukan integrasi sistem. Jika Anda punya waktu dan Anda melakukan ini, pastikan untuk membaca apa yang dikatakan Arno Gourdol, salah satu insinyur Mac OS X pertama:
Kami ingin menginstal aplikasi semudah menyeret ikon aplikasi dari suatu tempat (server, drive eksternal) ke disk komputer Anda. Untuk melakukan ini, semua informasi disimpan dalam paket aplikasi, termasuk ikon, versi, jenis file yang sedang diproses, jenis skema URL yang harus diketahui sistem untuk memproses aplikasi. Ini juga termasuk informasi untuk 'penyimpanan terpusat' di basis data Icon Services dan Launch Services. Untuk mempertahankan kinerja, aplikasi 'ditemukan' di beberapa tempat 'terkenal': dalam sistem dan direktori pengguna Aplikasi, serta di beberapa tempat lain, secara otomatis jika pengguna telah pindah ke Finder ke direktori yang berisi aplikasi. Dalam praktiknya, ini bekerja dengan sangat baik.
https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Sesi 144 - Mac OS X: Aplikasi Pengemasan dan Dokumen Pencetakan.
Tidak ada yang serupa dengan infrastruktur ini di desktop Linux, jadi kami mencari solusi di sekitar kendala struktural dalam proyek AppImage.
Apakah Haiku terburu-buru untuk membantu?
Dan satu hal lagi: platform Linux sebagai dasar lingkungan kerja, sebagai suatu peraturan, sangat tidak ditentukan sehingga banyak hal yang sangat sederhana dalam sistem yang konsisten dengan tumpukan penuh mengecewakan fragmentasi dan kompleksitas Linux. Saya mencurahkan seluruh laporan untuk masalah yang terkait dengan platform Linux untuk lingkungan kerja (pengembang berpengetahuan luas telah mengkonfirmasi: semuanya akan tetap demikian untuk waktu yang sangat lama).
Laporan saya tentang lingkungan desktop Linux pada tahun 2018
Bahkan Linus Torvalds mengakui bahwa itu karena fragmentasi bahwa ide lingkungan kerja gagal.
Senang melihat Haiku!
Dengan Haiku, semuanya luar biasa sederhana.
Meskipun pendekatan naif untuk port AppImage ke Haiku adalah dengan hanya mencoba membangun (terutama runtime.c dan layanan) komponennya (yang bahkan mungkin!), Itu tidak akan membawa banyak manfaat bagi Haiku. Karena pada kenyataannya sebagian besar masalah ini telah diselesaikan oleh Haiku dan secara konseptual dibenarkan. Haiku menyediakan batu bata untuk infrastruktur sistem yang sudah lama saya cari di lingkungan desktop Linux dan tidak bisa percaya bahwa mereka tidak ada di sana. Yaitu:
Percaya atau tidak, banyak pengguna Linux tidak bisa mengatasinya. Di Haiku, semuanya dilakukan secara otomatis!
- File ELF yang tidak memiliki bit yang dapat dieksekusi menerimanya secara otomatis ketika Anda mengklik dua kali pada file manager.
- Aplikasi dapat memiliki sumber daya yang disematkan, misalnya, ikon yang muncul di manajer file. Anda tidak perlu menyalin banyak gambar ke direktori ikon khusus, dan karena itu, Anda tidak perlu membersihkannya setelah menghapus atau memindahkan aplikasi.
- Ada database untuk menghubungkan aplikasi dengan dokumen, tidak perlu menyalin file apa pun untuk ini.
- Dalam direktori lib / di sebelah executable, perpustakaan dicari secara default.
- Tidak ada banyak distribusi dan lingkungan desktop, semua yang berfungsi - berfungsi di mana saja.
- Tidak ada modul terpisah untuk peluncuran yang berbeda dari direktori Aplikasi.
- Aplikasi tidak memiliki jalur absolut bawaan untuk sumber dayanya, ada fungsi khusus untuk menentukan lokasi saat runtime.
- Gagasan gambar sistem file terkompresi telah diperkenalkan: ini adalah paket hpkg. Semuanya dipasang oleh inti.
- Setiap file dibuka oleh aplikasi yang membuatnya, kecuali jika Anda secara eksplisit menentukan sesuatu yang lain. Betapa mengagumkannya itu!
Dua file png. Perhatikan berbagai ikon yang menunjukkan bahwa mereka akan dibuka oleh aplikasi yang berbeda dengan mengklik dua kali. Perhatikan juga menu tarik-turun "Buka dengan:", di mana pengguna dapat memilih aplikasi terpisah. Mudah sekali!
Sepertinya banyak kruk dan solusi yang diperlukan oleh AppImage di Linux menjadi tidak perlu di Haiku, yang didasarkan pada kesederhanaan dan kecanggihan, berkat itu mengatasi sebagian besar kebutuhan kita.
Apakah Haiku membutuhkan paket aplikasi pada akhirnya?
Ini mengarah pada pertanyaan besar. Jika itu akan menjadi urutan besarnya lebih mudah untuk membuat sistem seperti AppImage di Haiku daripada di Linux, apakah itu layak? Atau apakah Haiku dengan sistem paket hpkgnya secara virtual menghilangkan kebutuhan untuk mengembangkan ide semacam itu? Nah, untuk jawabannya Anda perlu melihat motivasi untuk keberadaan AppImages.
Lihat dari pengguna
Lihatlah pengguna akhir kami:
- Saya ingin menginstal aplikasi tanpa meminta kata sandi administrator (root). Di Haiku tidak ada konsep administrator, pengguna memiliki kontrol penuh, karena ini adalah sistem pribadi! (Pada prinsipnya, Anda bisa membayangkan ini dalam mode multi-pengguna, saya harap para pengembang akan menjaga kesederhanaan)
- Saya ingin mendapatkan versi terbaru dan terbaik dari aplikasi, tidak menunggu mereka muncul di distribusi saya (paling sering itu berarti "tidak pernah", setidaknya jika Anda tidak memperbarui seluruh OS). Di Haiku, ini "diselesaikan" dengan rilis mengambang. Ini berarti Anda bisa mendapatkan versi terbaru dan terbaik dari aplikasi, tetapi untuk ini Anda harus terus memperbarui sisa sistem, benar-benar mengubahnya menjadi "target bergerak" .
- Saya ingin beberapa versi aplikasi yang sama di dekatnya, karena Anda tidak dapat menemukan apa yang rusak di versi terbaru, atau, sebagai contoh, sebagai pengembang web, saya perlu memeriksa pekerjaan saya di bawah berbagai versi browser. Haiku memecahkan yang pertama, tetapi bukan masalah yang kedua. Pembaruan dibatalkan, tetapi hanya untuk seluruh sistem, tidak mungkin (seperti yang saya tahu) untuk meluncurkan, misalnya, beberapa versi WebPositive atau LibreOffice pada saat yang sama.
Salah satu pengembang menulis:
Intinya, alasannya adalah ini: use case sangat jarang sehingga optimasi tidak masuk akal untuk itu; menanganinya sebagai kasus khusus di HaikuPorts tampaknya lebih dari cukup.
- Saya perlu menyimpan aplikasi di tempat yang saya suka, dan bukan pada disk boot. Saya sering kehabisan ruang pada disk, jadi saya harus menghubungkan drive eksternal atau direktori jaringan untuk menyimpan aplikasi (semua versi yang saya unduh). Jika saya menghubungkan drive seperti itu, saya perlu aplikasi untuk diluncurkan dengan mengklik dua kali. Haiku menyimpan versi paket yang lebih lama, tetapi saya tidak tahu cara memindahkannya ke drive eksternal, atau bagaimana memanggil aplikasi dari sana nanti.
Komentar Pengembang:
Secara teknis, ini sudah dimungkinkan dengan perintah mount. Tentu saja, kami akan membuat GUI untuk ini segera setelah cukup banyak pengguna yang tertarik.
- Saya tidak membutuhkan jutaan file yang tersebar di sekitar 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 bantuan paket
.hpkg , yang mentransfer, misalnya python, dari ribuan file ke satu. Tetapi jika ada, misalnya, Scribus menggunakan python, maka saya harus berurusan dengan setidaknya dua file. Dan saya harus berhati-hati agar versi mereka bekerja satu sama lain.
Sejumlah versi AppImages berjalan berdampingan di satu Linux
Lihat dari sisi pengembang aplikasi
Mari kita lihat dari sudut pandang pengembang aplikasi:
- Saya ingin mengelola seluruh pengalaman pengguna. Saya tidak ingin bergantung pada sistem operasi, yang akan memberi tahu saya kapan dan bagaimana saya harus merilis aplikasi. Di Haiku, pengembang dapat bekerja dengan repositori hpkg mereka sendiri, tetapi ini berarti bahwa pengguna harus mengonfigurasi mereka secara manual, yang membuat ide ini kurang menarik.
- Saya memiliki halaman unduh di situs web tempat saya mendistribusikan
.exe untuk Windows, .dmg untuk Mac, dan .AppImage untuk Linux. Atau mungkin saya ingin memonetisasi akses ke halaman ini, apakah semuanya bisa? Apa yang harus saya kirim ke Haiku? Cukup file .hpkg dengan dependensi .hpkg - Perangkat lunak saya memerlukan versi tertentu dari perangkat lunak lain. Misalnya, diketahui bahwa Krita memerlukan versi tetap Qt, atau Qt, yang disesuaikan dengan versi Krita tertentu, setidaknya sampai koreksi kembali ke Qt. Anda dapat mengemas Qt Anda sendiri untuk aplikasi dalam paket
.hpkg , tetapi kemungkinan besar ini tidak diterima.
Halaman pengunduhan aplikasi normal. Apa yang harus dilakukan di sini untuk Haiku?
Apakah bundel (yang ada sebagai direktori aplikasi seperti AppDir atau .app dalam gaya Apple) dan / atau gambar (seperti AppImages atau .dmg Apple yang banyak dimodifikasi) menjadi tambahan yang berguna untuk lingkungan kerja Haiku? Atau akankah itu mencairkan seluruh gambar dan menyebabkan fragmentasi, dan karenanya menambah kompleksitas? Saya terkoyak: di satu sisi, keindahan dan kecanggihan Haiku didasarkan pada kenyataan bahwa biasanya ada satu cara untuk melakukan sesuatu, tidak banyak. , / , , .
mr. waddlesplash
Linux ( , — . ) . Haiku .
?
...
, : — Haiku:
Haiku,
, , , Macintosh Finder. , QtCreator "QtCreator", ?
:
, , ? , - ?
Haiku, ? , .
mr. waddlesplash:
, : , , - . BeOS R5 Haiku — ...
!
Haiku?
hpkg, :
.hpkg- ( , )
.hpkg ( 80% ) - ,
.hpkg , ( , QtCreator): .hpkg , .
mr. waddlesplash :
, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .
- Haiku , , , , " ", , ( 20% ).
.hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).
mr. waddlesplash:
. "" pkgman .
hpkg, . , .
Kesimpulan
Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?
! Haiku DVD USB, .
? telegram- .
: C C++. Haiku OS
: Haiku.
Daftar artikel: pertama kedua ketiga keempat kelima keenam ketujuh kedelapan kesembilan