🥇Hari keenam saya bersama Haiku: di balik terpal sumber daya, ikon, dan paket

TL; DR: Haiku adalah sistem operasi yang dirancang khusus untuk PC, sehingga memiliki beberapa trik yang membuat lingkungan desktopnya jauh lebih baik daripada yang lain. Tapi bagaimana cara kerjanya?

Baru-baru ini Saya menemukan Haiku, sistem yang sangat bagus. Saya masih kagum dengan kelancarannya, terutama dibandingkan dengan lingkungan desktop Linux. Hari ini saya akan melihat di balik terpal. Jika diperlukan untuk pemahaman mendalam, saya akan membuat perbandingan dengan lingkungan desktop Macintosh, Mac OS X dan Linux asli (standar XDG dari freedesktop.org).

Sumber daya dalam file ELF

Kemarin saya mengetahui bahwa IconOmatic dapat menyimpan ikon di sumber daya rdef di executable ELF. Hari ini saya ingin melihat cara kerjanya.

Sumber daya? Mengutip dari Bruce Tanduk, penulis asli Macintosh Finder dan "bapak" dari Macintosh Resource Manager:

Saya khawatir dengan sifat kaku dari pengkodean tradisional. Bagi saya, gagasan tentang aplikasi yang dibekukan dalam kode, tanpa kemampuan untuk mengubah apa pun secara dinamis, adalah kebiadaban yang paling liar. Seharusnya dapat diubah sebanyak mungkin pada saat runtime. Tentu saja kode aplikasinya sendiri tidak bisa diubah, tapi pasti ada yang bisa diubah tanpa mengkompilasi ulang kodenya?

Di Macintosh asli, mereka membuat file-file ini memiliki “bagian data” dan “bagian sumber daya”, yang membuatnya sangat mudah untuk menyimpan hal-hal seperti ikon, terjemahan, dan sejenisnya. dalam file yang dapat dieksekusi.

Di Mac ini digunakan Sunting Ulang, program grafis untuk - tiba-tiba - mengedit sumber daya.

ResEdit di Macintosh asli

Hasilnya, dimungkinkan untuk mengedit ikon, item menu, terjemahan, dll. cukup mudah, namun mereka tetap “bepergian” dengan aplikasi tersebut.
Bagaimanapun, pendekatan ini memiliki kelemahan besar: pendekatan ini hanya berfungsi pada sistem file Apple, yang merupakan salah satu alasan mengapa Apple mengabaikan “bagian sumber daya” saat berpindah ke Mac OS X.
Di Mac OS X, Apple menginginkan solusi yang tidak bergantung pada sistem file, jadi mereka mengadopsi konsep paket (dari NeXT), direktori yang diperlakukan sebagai "objek buram" oleh pengelola file, seperti file, bukan direktori. Paket apa pun dengan aplikasi dalam format .app memiliki, antara lain, sebuah file Info.plist (dalam semacam JSON atau YAML milik Apple) yang berisi metadata aplikasi.

Kunci untuk file Info.plist dari paket aplikasi Mac OS X.

Sumber daya, seperti ikon, file UI, dan lainnya, disimpan dalam paket sebagai file. Konsep ini sebenarnya kembali ke akarnya di NeXT.

Mathematica.app di NeXTSTEP 1.0 pada tahun 1989: muncul sebagai direktori file di terminal, tetapi sebagai objek tunggal di pengelola file grafis.

Mari kembali ke BeOS, konsep yang menjadi dasar Haiku. Pengembangnya, ketika beralih dari PEF (PowerPC) ke ELF (x86) (sama seperti yang digunakan di Linux), memutuskan untuk menambahkan bagian sumber daya di akhir file ELF. Itu tidak menggunakan bagian ELF yang sebenarnya, itu hanya ditambahkan ke akhir file ELF. Sebagai hasil dari program tersebut strip dan yang lain dari binutils, tidak menyadarinya, potong saja. Oleh karena itu, saat menambahkan sumber daya ke file ELF di BeOS, sebaiknya jangan memanipulasinya dengan alat Linux.

Apa yang terjadi dengan Haiku sekarang? Pada dasarnya kurang lebih sama.

Secara teori, dimungkinkan untuk menempatkan sumber daya di bagian ELF yang diinginkan. Menurut pengembang di saluran #haiku di irc.freenode.net:

Dengan ELF bagian ini akan lebih masuk akal... satu-satunya alasan kami tidak melakukannya adalah karena itulah yang kami lakukan di BeOS."
Dan tidak ada gunanya mengubahnya sekarang.

Pengelolaan sumber daya

Sumber daya ditulis dalam format “sumber daya” terstruktur: pada dasarnya daftar sumber daya dengan ukuran dan kemudian isinya. Aku teringat format ar.
Bagaimana cara memeriksa sumber daya di Haiku? Apakah ada yang seperti ResEdit?
Menurut dokumentasi:

Untuk melihat sumber daya yang disediakan dalam paket aplikasi, Anda dapat menyeret file yang dapat dieksekusi ke program seperti Narasumber. Anda juga dapat pergi ke terminal dan menjalankan perintah listres имя_файла.

Resourcer tersedia di HaikuDepot, tetapi bagi saya crash saja.

Bagaimana cara mengelola sumber daya dalam file ELF? Menggunakan rsrc и rdef. rdef file dikumpulkan di rsrc. Mengajukan rdef disimpan dalam format teks biasa, sehingga lebih mudah untuk digunakan. Format berkas rsrc ditambahkan ke akhir file ELF. Ayo coba mainkan:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

Anda dapat menggunakan program ini xres untuk pemeriksaan dan pengendalian:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

Oke, mari kita coba?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

Lebih lanjut tentang sumber daya dan format rdef bisa membaca di sini.

Jenis sumber daya standar

Meskipun Anda dapat memasukkan apa pun ke dalam sumber daya, ada beberapa tipe standar yang ditentukan:

app_signature: Jenis aplikasi MIME, untuk pemetaan buka file, peluncuran, IPC, dll.
app_name_catalog_entry: Karena nama aplikasi biasanya dalam bahasa Inggris, Anda dapat menentukan lokasi di mana nama terjemahan berada, sehingga pengguna bahasa berbeda akan melihat nama aplikasi terjemahan jika diinginkan.
app_version: persis seperti yang Anda pikirkan
app_flags: menunjukkan registrar cara memproses lamaran. Saya pikir ada lebih dari yang terlihat. Misalnya ada B_SINGLE_LAUNCH, yang memaksa sistem untuk meluncurkan proses aplikasi baru setiap kali pengguna memintanya (prinsip yang sama digunakan untuk sebagian besar aplikasi di Linux). Makan B_MULTIPLE_LAUNCH, menyebabkan proses berjalan setiap file. Akhirnya ada B_EXCLUSIVE_LAUNCH, yang memaksa sistem untuk meluncurkan hanya satu proses pada satu waktu, tidak peduli seberapa sering pengguna meluncurkannya (misalnya, ini adalah cara Firefox berjalan di Linux; hasil yang sama dapat dicapai dalam aplikasi Qt menggunakan fungsi tersebut QtSingleApplication). Aplikasi dengan B_EXCLUSIVE_LAUNCH diberitahukan ketika pengguna mencoba menjalankannya lagi: misalnya, mereka menerima jalur file yang ingin dibuka pengguna dengan bantuan mereka.
vector_icon: Ikon aplikasi vektor (BeOS tidak memiliki ikon vektor, sebagian besar aplikasi memiliki dua ikon raster dalam file yang dapat dieksekusi).

Tentu saja, Anda dapat menambahkan sumber daya dengan ID dan tipe apa pun yang diinginkan, lalu membacanya di aplikasi itu sendiri atau aplikasi lain yang menggunakan kelas tersebut BResources. Namun pertama-tama, mari kita lihat topik menarik tentang ikon.

Ikon vektor dalam gaya Haiku

Tentu saja, Haiku tidak hanya memilih format ikon terbaik; pada bagian ini, situasi dengan lingkungan desktop Linux jauh dari ideal:

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

Melihat ini Anda sudah bisa merasakan betapa hebatnya karya itu.

Tentu saja, ada scalable, yang berisi, seperti yang Anda pahami, ikon vektor. Lalu mengapa ada hal lain? Pasalnya, hasil menggambar grafik vektor dalam ukuran kecil mungkin kurang ideal. Saya ingin opsi berbeda dioptimalkan untuk ukuran berbeda. Di lingkungan desktop Linux, hal ini dicapai dengan menyebarkan ikon dengan ukuran berbeda ke seluruh sistem file.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

Harap diperhatikan: tidak ada konsep versi Firefox yang berbeda. Oleh karena itu, tidak mungkin menangani situasi memiliki beberapa versi aplikasi pada sistem dengan baik.

Ikon Firefox berbeda dalam versi berbeda. Saat ini tidak mungkin untuk menangani hal ini di Linux tanpa berbagai kruk.

Mac OS X menanganinya dengan lebih halus:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

Terlihat ada satu file firefox.icns dalam paket Firefox.app, berisi semua ukuran sehingga versi berbeda dari aplikasi yang sama memiliki ikon berbeda.
Jauh lebih baik! Ikon bepergian bersama aplikasi, semua sumber daya ada dalam satu file.

Mari kita kembali ke Haiku. Sebuah solusi yang menakjubkan, tanpa pengecualian. Berdasarkan dokumentasi:

Format HVIF khusus, yang sangat dioptimalkan untuk ukuran kecil dan rendering cepat, dikembangkan. Oleh karena itu, sebagian besar ikon kami jauh lebih kecil dibandingkan raster atau format SVG yang banyak digunakan.

Dan mereka masih dioptimalkan:

Ukuran ikon dalam HVIF dibandingkan dengan format lain.

Perbedaannya sangat besar!

Namun keajaibannya tidak berakhir di sini. HVIF yang sama dapat menampilkan tingkat detail yang berbeda tergantung pada ukuran yang ditampilkan, meskipun formatnya vektor.

Tingkat detail (LOD) yang berbeda bergantung pada ukuran render

Sekarang tentang kerugiannya: Anda tidak dapat mengambil SVG, melemparkannya ke ImageMagick dan menghentikannya; Anda harus melalui beberapa siklus untuk membuat ikon dalam format HVIF. Di sini penjelasan. Namun, IconOmatic dapat mengimpor SVG dengan tidak sempurna; sekitar 90% detail SVG diimpor dengan kemungkinan tertentu, 10% sisanya perlu dikonfigurasi dan diubah secara manual. Baca selengkapnya tentang bagaimana HVIF melakukan keajaibannya satu bisa di blog Leah Ganson

Menambahkan ikon ke aplikasi

Sekarang saya dapat menambahkan ikon ke paket yang dibuat terakhir kali, dengan mempertimbangkan semua informasi yang diterima.
Ya, karena saya tidak terlalu bersemangat untuk menggambar ikon saya sendiri untuk QtQuickApp “Halo, Dunia” saya saat ini, saya mengeluarkannya dari Qt Creator.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

Mari kita periksa apakah ikon telah disalin:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Kelihatannya bagus, tapi kenapa saat disalin ikon baru tidak muncul?

VICN:101:BEOS:ICONs yang disalin belum digunakan sebagai ikon aplikasi di pengelola file

Apa yang saya lewatkan?

Komentar pengembang:

Kita perlu membuat file rdef dengan semua sumber daya, lalu jalankan perintah rc имя.rdef, ini akan membuat file .rsrc. Maka Anda perlu menjalankan perintah resattr -o имя_бинарника имя.rsrc. Minimal, saya menggunakan perintah seperti ini untuk menambahkan ikon ke skrip saya.

Ya, saya ingin membuat sumber daya, bukan atribut. Saya benar-benar bingung.

Caching cerdas menggunakan sistem file

Membuka dan membaca atribut ELF lambat. Seperti yang saya tulis di atas, ikon ditulis sebagai sumber daya di file itu sendiri. Metode ini lebih andal dan memungkinkan Anda bertahan saat menyalin ke sistem file lain. Namun, kemudian juga disalin ke atribut sistem file, misalnya BEOS:ICON. Ini hanya berfungsi pada sistem file tertentu, seperti BFS. Ikon yang ditampilkan oleh sistem (di Tracker dan Deskbar) dibaca dari atribut yang diperluas ini, karena solusi ini bekerja dengan cepat. Di beberapa tempat (di mana kecepatan tidak penting, misalnya, jendela “Tentang”), sistem menerima ikon langsung dari sumber daya dalam file. Tapi ini bukanlah akhir. Ingat, di Mac, pengguna dapat mengganti ikon aplikasi, direktori, dokumen dengan miliknya sendiri, karena di Mac dimungkinkan untuk melakukan hal-hal “penting” ini, misalnya mengganti ikon Slack baru dengan yang sebelumnya. Di Haiku, Anda harus menganggap sumber daya (dalam file) sebagai ikon asli yang disertakan dengan aplikasi, dan atribut (dalam sistem file BFS) sebagai sesuatu yang memungkinkan pengguna membuat perubahan sesuka hati (walaupun, petunjuk, GUI untuk menyisipkan ikon khusus di atas ikon bersifat opsional) (belum diterapkan secara default).

Memeriksa atribut sistem file

Dengan resaddr Dimungkinkan untuk memeriksa dan mengatur atribut sistem file.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

Ini pada dasarnya adalah "perekat" yang melakukan konversi bolak-balik antara sumber daya (yang dapat diandalkan) dan atribut sistem file (cepat). Dan karena sistem mengharapkan untuk menerima sumber daya dan melakukan penyalinan secara otomatis, saya tidak akan mengkhawatirkannya lebih jauh.

Keajaiban paket hpkg

Saat ini (paling sering) paket digunakan untuk mendapatkan program di Haiku .hpkg. Jangan terkecoh dengan nama sederhananya: format .hpkg bekerja sangat berbeda dari format lain dengan nama serupa yang pernah Anda temui, format ini memiliki kekuatan super yang nyata.

Dengan format paket tradisional, saya kecewa untuk waktu yang lama karena fakta ini: Anda mengunduh satu hal (paket), dan yang lain diinstal pada sistem (file di dalam paket). Cukup sulit untuk mengelola file (misalnya menghapusnya) saat menginstal paket dengan cara tradisional. Dan semua itu karena isi paketnya tersebar di seluruh sistem file, termasuk tempat-tempat yang rata-rata penggunanya mungkin tidak memiliki akses tulis. Hal ini memunculkan seluruh kelas program - manajer paket. Namun mentransfer perangkat lunak yang sudah terinstal, misalnya, ke komputer lain, diska lepas, atau server file menjadi lebih sulit, bahkan tidak mungkin sama sekali. Pada sistem berbasis Linux pada umumnya, terdapat beberapa ratus ribu hingga jutaan file individual. Tentu saja, ini rapuh dan lambat, misalnya saat pertama kali menginstal sistem, saat menginstal, memperbarui, dan menghapus instalasi paket reguler, dan saat menyalin volume boot (partisi root) ke media lain.

Saya sedang mengerjakan proyek AppImage, sebagian penopang untuk aplikasi pengguna akhir. Ini adalah format distribusi perangkat lunak yang mengumpulkan aplikasi dan semua dependensinya ke dalam satu image sistem file yang dipasang saat aplikasi dimulai. Menyederhanakan banyak hal secara signifikan, karena ImageMagick yang sama tiba-tiba berubah menjadi satu file, dikelola di pengelola file oleh manusia biasa. Metode yang diusulkan hanya berfungsi untuk perangkat lunak, sebagaimana tercermin dalam nama proyeknya, dan juga memiliki serangkaian masalahnya sendiri, karena orang-orang yang terlibat dalam pembuatan perangkat lunak untuk Linux selalu mengarahkan panah ke arah saya.

Mari kita kembali ke Haiku. Apakah mungkin untuk menemukan keseimbangan optimal antara sistem paket tradisional dan pengiriman perangkat lunak berbasis gambar? Paketnya .hpkg sebenarnya gambar sistem file terkompresi. Saat sistem melakukan booting, kernel memasang semua paket yang terinstal dan aktif dengan kira-kira pesan kernel berikut:

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

Keren, ya? Bertahanlah, itu akan lebih keren lagi!

Ada paket yang sangat spesial:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Ini berisi sistem operasi yang sangat minimalis, termasuk kernel. Percaya atau tidak, bahkan kernel itu sendiri tidak dihapus dari volume boot (partisi root), tetapi dimuat dengan hati-hati dari paket ke tempatnya. .hpkg. Wow! Saya telah menyebutkan bahwa menurut saya sebagian dari keseluruhan kecanggihan dan konsistensi Haiku berasal dari fakta bahwa keseluruhan sistem, mulai dari kernel dan ruang pengguna inti hingga manajemen paket dan infrastruktur runtime, dikembangkan secara kolaboratif oleh satu tim. Bayangkan berapa banyak grup dan tim berbeda yang diperlukan untuk menjalankan hal seperti ini di Linux [Saya membayangkan proyek PuppyLinux - kira-kira. Penerjemah]. Lalu bayangkan berapa lama waktu yang dibutuhkan untuk menerapkan pendekatan ini ke dalam distribusi. Mereka berkata: ambillah masalah yang sederhana, bagilah di antara pelaku yang berbeda, dan masalah itu akan menjadi sangat rumit sehingga tidak mungkin lagi untuk menyelesaikannya. Haiku dalam hal ini membuka mataku. Saya pikir inilah yang sebenarnya terjadi di Linux sekarang (Linux dalam hal ini adalah istilah kolektif untuk tumpukan Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Pengembalian sistem menggunakan hpkg

Seberapa sering situasi berikut terjadi: pembaruan berhasil, dan ternyata ada sesuatu yang tidak berfungsi sebagaimana mestinya? Jika Anda menggunakan pengelola paket konvensional, sulit untuk mengembalikan keadaan sistem ke titik waktu sebelum paket baru diinstal (misalnya, jika terjadi kesalahan). Beberapa sistem menawarkan solusi dalam bentuk snapshot sistem file, namun cukup rumit dan tidak digunakan di semua sistem. Haiku menyelesaikan ini menggunakan paket .hpkg. Setiap kali paket berubah di sistem, paket lama tidak dihapus, tetapi disimpan di sistem dalam subdirektori seperti /Haiku/system/packages/administrative/state-<...>/ selalu. Operasi yang belum selesai menyimpan datanya di subdirektori /Haiku/system/packages/administrative/transaction-<...>/.

Konten /Haiku/system/packages/administrative. Direktori “state…” berisi file teks dengan nama paket yang aktif, dan direktori “transaction…” berisi paket itu sendiri.

"Keadaan aktif lama", mis. daftar .hpkg paket aktif sebelum perubahan dicatat setelah setiap operasi di pengelola file dalam file teks /Haiku/system/packages/administrative/state-<...>/activated-packages. Dengan cara yang sama, “keadaan aktif” baru ditulis dalam file teks /Haiku/system/packages/administrative/activated-packages.

Direktori /Haiku/system/packages/administrative/state-<...>/ hanya berisi file teks dengan daftar paket aktif dari status ini (dalam hal instalasi paket tanpa penghapusan), dan jika paket dihapus atau diperbarui - direktori status berisi paket versi lama.

Saat sistem melakukan booting, berdasarkan daftar paket, keputusan dibuat untuk mengaktifkan (memasang) paket. Sesederhana itu! Jika terjadi kesalahan selama pengunduhan, Anda dapat meminta pengelola unduhan untuk menggunakan daftar lain yang lebih lama. Masalah terpecahkan!

Pengunduh Haiku. Setiap titik masuk menampilkan "keadaan aktif" yang sesuai

Saya menyukai pendekatan yang memiliki file teks sederhana sebagai daftar "keadaan aktif", dengan nama yang mudah dimengerti .hpkg. Hal ini sangat kontras dengan teknologi yang dibuat untuk mesin, bukan untuk manusia. kelompok dari OSTree atau Flatpak di sistem file (pada level yang sama dengan Microsoft GUID).

Daftar paket aktif untuk setiap titik waktu

Data konfigurasi

Rupanya, di katalog /Haiku/system/packages/administrative/writable-files berisi file konfigurasi untuk paket, tetapi dapat ditulis. Lagi pula, seperti yang Anda ingat, .hpkg dipasang hanya-baca. Jadi file-file ini harus disalin dari paket sebelum ditulis. Memiliki arti.

Integrasi GUI untuk sistem .hpkg

Sekarang mari kita lihat bagaimana tas mengkilap ini .hpkg mengatasi integrasi ke dalam lingkungan kerja pengguna (UX). Lagipula, Haiku ditujukan untuk penggunaan pribadi. Secara pribadi, saya menetapkan standar yang tinggi ketika membandingkan pengalaman pengguna dengan paket .app di Macintosh dengan pengalaman yang sama .hpkg. Saya bahkan tidak akan membandingkan situasinya dengan lingkungan kerja di Linux, karena ini benar-benar buruk dibandingkan dengan lingkungan lainnya.

Skenario berikut muncul dalam pikiran:

Saya ingin melihat isi sebuah paket .hpkg
Saya ingin menginstal sebuah paket
Saya ingin menghapus paket itu
Saya ingin menghapus sesuatu yang masuk ke sistem sebagai bagian dari sebuah paket
Saya ingin menyalin sesuatu yang masuk ke sistem sebagai bagian dari sebuah paket
Saya ingin mengunduh semua dependensi suatu paket, yang mungkin tidak menjadi bagian dari setiap instalasi Haiku (misalnya, saya memiliki mesin yang terisolasi secara fisik tanpa akses internet.)
Saya ingin memindahkan paket saya (atau sebagian darinya) secara terpisah ke lokasi lain, terpisah dari volume boot (partisi root) (karena, misalnya, saya tidak punya cukup ruang di dalamnya).

Ini harus mencakup sebagian besar kasus-kasus besar dari pekerjaan saya sehari-hari. Baiklah, mari kita mulai.

Memeriksa isi paket

Di Mac Saya cukup klik kanan pada paket untuk membukanya dan melihat isinya di Finder. Bagaimanapun, pada kenyataannya ini hanyalah direktori yang disamarkan! (Saya tahu ada paket .pkg untuk bagian sistem yang bukan aplikasi, tetapi pengguna biasa paling sering tidak berinteraksi dengannya).

Di Haiku Saya klik kanan pada paketnya, lalu klik "Isi" untuk melihat isinya. Tapi ini hanya daftar file tanpa kemampuan untuk membukanya dengan mengklik dua kali.
Akan jauh lebih baik jika ada cara untuk (sementara) me-mount paket tersebut .hpkg untuk dilihat melalui pengelola file, dan pengguna tidak perlu khawatir tentang detail implementasi. (Omong-omong, Anda bisa membukanya .hpkg paket masuk Expander, yang dapat membongkarnya seperti arsip lainnya).

Antarmuka HaikuDepot memungkinkan Anda melihat daftar file paket, tetapi tidak ada cara untuk melihat isinya, misalnya dengan mengklik dua kali README.md

Mac menang dalam kategori ini, tetapi menambahkan fungsionalitas HaikuDepot yang Anda inginkan seharusnya tidak terlalu sulit.

Menginstal paket melalui GUI

Di Mac, sebagian besar gambar disk .dmg berisi paket .app. Klik dua kali image disk lalu salin paketnya, misalnya dengan menyeretnya ke dalam /Applications di Penemu. Bagi saya, hal ini tidak perlu dikatakan lagi, tetapi saya pernah mendengar bahwa beberapa pemula mungkin tidak dapat menangani hal ini. Secara default, Apple "menyarankan" direktori seluruh sistem /Applications (di NeXT itu jaringan dan juga individual), tetapi Anda dapat dengan mudah meletakkan aplikasi Anda di server file atau di subdirektori $HOME/Applications, jika Anda suka seperti itu.

Di Haiku, klik dua kali pada paketnya, lalu klik “Instal”, ini sangat mudah. Saya bertanya-tanya apa yang terjadi jika suatu paket memiliki dependensi yang tersedia di HaikuPorts tetapi belum diinstal. Di Linux mereka benar-benar tidak tahu apa yang harus dilakukan dalam situasi ini, tetapi solusinya jelas - tanyakan kepada pengguna apakah mereka perlu mengunduh dan menginstal dependensi. Persis seperti yang dilakukan Haiku.

Saya mengunduh paket 'sanity' secara manual dan mengkliknya, manajer paket tahu dari mana mendapatkan dependensinya (dengan asumsi repositori sudah terdaftar di sistem). Tidak semua distribusi Linux dapat melakukan hal ini.

Cara lainnya adalah dengan menggunakan file manager, cukup drag and drop .hpkg paket atau masuk /Haiku/system/packages (untuk instalasi seluruh sistem, secara default), atau di /Haiku/home/config/packages (untuk instalasi individual; tidak tersedia saat mengklik dua kali - Saya masih kesal dengan kata "config" di tempat ini, yang bagi saya dalam hal ini identik dengan "pengaturan"). Dan konsep banyak pengguna bahkan belum tersedia untuk Haiku (mungkin itulah alasannya sangat sederhana - saya tidak tahu, mungkin kemampuan multi-pengguna akan memperumit masalah yang tidak perlu untuk lingkungan desktop desktop).

Haiku menang dalam kategori ini karena tidak hanya dapat bekerja dengan aplikasi, tetapi juga dengan program sistem.

Menghapus paket dari GUI

Di Mac, Anda perlu menyeret ikon aplikasi ke tempat sampah, dan itu saja. Mudah!

Di Haiku, pertama, Anda perlu mencari lokasi paket di sistem, karena Anda jarang menginstalnya di tempat yang tepat (sistem melakukan semuanya). Biasanya Anda perlu melihat ke dalam /Haiku/system/packages (dengan instalasi default seluruh sistem), atau di /Haiku/home/config/packages (Apakah saya menyebutkan bahwa “config” adalah istilah yang keliru?). Kemudian aplikasi tersebut cukup diseret ke tempat sampah, dan selesai.
Mudah! Namun, saya tidak akan mengatakan itu. Inilah yang sebenarnya terjadi:

Inilah yang terjadi jika Anda menyeret aplikasi ke tempat sampah /Haiku/system/packages

Baru saja mencoba memindahkan aplikasi "Hello World" saya kemarin di QtQuickApp ke tempat sampah. Saya tidak mencoba memindahkan direktori sistem, dan karena semua paket diinstal di direktori sistem, tidak mungkin untuk menghapus paket tersebut .hpkg tanpa perubahan "isinya". Pengguna biasa akan merasa takut dan menekan tombol “Batal” yang ditetapkan secara default.

Menjelaskan Tn. waddlesplash:

Postingan ini berusia lebih dari 10 tahun. Kemungkinan besar kita perlu mengkonfigurasinya agar peringatan hanya muncul ketika paket itu sendiri dipindahkan. Pengguna biasa tidak perlu melakukan ini.

Oke, mungkin saya harus melakukan ini menggunakan HaikuDepot? Saya klik dua kali pada paket yang masuk /Haiku/system/packages, menunggu tombol “Uninstall” muncul. Tidak, yang ada (hanya) “Instal”. "Copot", kamu dimana?

Sekadar iseng, saya mencoba melihat apa yang akan terjadi jika saya mengklik “Instal” pada paket yang sudah terinstal. Ternyata seperti ini:

Hal ini terjadi jika Anda mencoba menginstal paket yang sudah terinstal.

Berikutnya muncul:

Jika Anda mengklik “Terapkan perubahan” di jendela sebelumnya, tampilannya akan seperti ini

Saya berasumsi ini adalah kesalahan perangkat lunak; tautan ke aplikasi sudah ada. [penulis tidak memberikan tautan - kira-kira. Penerjemah]

Solusi cepat: Tambahkan tombol "Uninstall" jika paket sudah ada /Haiku/system/packages, atau dalam /Haiku/home/config/packages.

Saat melihat daftar paket yang diinstal di HaikuDepot, saya melihat paket saya di daftar dan dapat menghapusnya.

Mac menang dalam kategori ini. Namun saya dapat membayangkan bahwa dengan pengaturan yang tepat, pengalaman pengguna di Haiku akan lebih baik daripada di Mac. (Salah satu pengembang menilainya seperti ini: “Kurang dari satu jam untuk menambahkan fungsionalitas yang ditentukan ke HaikuDepot, jika Anda tahu sedikit C++”, ada sukarelawan?)

Menghapus sesuatu dari sebuah paket

Mari kita coba menghapus aplikasi itu sendiri, bukan paketnya .hpkg, dari mana asalnya (saya ragu bahwa bagi "manusia biasa" ada perbedaannya).

Di Mac, pengguna sebenarnya biasanya bekerja dengan file tersebut .dmgdari mana paket aplikasi itu berasal .app. Biasanya gambar .dmg terakumulasi di direktori unduhan, dan paket disalin oleh pengguna ke /Applications. Diyakini banyak pengguna sendiri yang tidak mengetahui apa yang mereka lakukan, hipotesis ini dibenarkan oleh mantan karyawan Apple. (Salah satu hal yang saya tidak suka di Mac. Dan, misalnya, dengan AppImage tidak ada perbedaan antara aplikasi dan paket di dalamnya. Seret ikon ke tempat sampah = itu saja. Mudah!)

Di Haiku, ada juga pembagian antara apps/ и packages/, jadi saya ragu hal ini dapat memperjelasnya bagi pengguna. Namun apa jadinya jika Anda menyeret aplikasi dari apps/ Masukkan ke keranjang:

Inilah yang terjadi ketika Anda mencoba menghapus aplikasi yang diambil dari sebuah file .hpkg

Secara teknis itu benar (bagaimanapun juga, aplikasi dihosting pada sistem file read-only), tapi itu tidak terlalu berguna bagi pengguna.

Solusi cepat: sarankan menggunakan GUI untuk menghapus .hpkg

Sekadar iseng, saya mencoba menduplikasi aplikasi dengan menekan Alt+D. Saya menerima pesan "Tidak dapat memindahkan atau menyalin objek pada volume hanya-baca." Dan semua itu karena /system (di samping itu /system/packages и /system/settings) adalah titik pemasangan packagefs (ingat tampilannya di output df?). Sayangnya, output dari perintah tersebut mount tidak memperjelas situasi (seperti yang disebutkan di salah satu artikel sebelumnya), mountvolume tidak menunjukkan apa yang Anda cari (tampaknya paket dipasang melalui loop .hpkg tidak dianggap "volume"), dan saya juga lupa perintah alternatifnya.

Tidak ada yang menang dalam kategori ini kecuali AppImage (tapi sejujurnya, ini adalah opini yang bias). Namun, dapat dibayangkan bahwa setelah penyesuaian, pengalaman pengguna di Haiku akan lebih baik daripada di Mac.

Catatan: Anda perlu mencari tahu apa itu “volume” dalam kaitannya dengan “bagian”. Ini mungkin mirip dengan hubungan "folder" dengan "direktori": sebagian besar direktori muncul sebagai folder di pengelola file, tetapi tidak semuanya (paket diperlakukan sebagai file, misalnya). Apakah tampilan seperti ini menjadikan saya seorang kutu buku resmi?

Menyalin isi paket ke sistem lain

Di Mac, dengan bodohnya saya menyeret paket itu .app, dan karena dependensinya ada di dalam paket, mereka berpindah bersama.

Di Haiku, saya drag aplikasinya, tapi dependensinya tidak diproses sama sekali.

Solusi cepat: Mari kita sarankan untuk menyeret seluruh paket `.hpkg, beserta dependensinya, jika ada.

Mac jelas menang dalam kategori ini. Setidaknya bagi saya, pecinta paradigma mereka. Saya harus menyalinnya ke Haiku .hpkg alih-alih aplikasi, tetapi sistem tidak menawarkan ini kepada saya...

Unduh paket dengan semua dependensinya

Tidak semua mesin terhubung ke jaringan sepanjang waktu. Sebaliknya, beberapa mesin (ya, saya melihat Anda, Windows modern, Mac dan Linux) melupakan hal ini. Penting bagi saya untuk pergi, misalnya, ke warnet, mengunduh perangkat lunak ke drive yang dapat dilepas, memasukkan drive ini ke komputer di rumah saya dan memastikan semuanya akan berfungsi [pria berisiko, melakukan ini di Windows... - kira-kira. Penerjemah].

Akibatnya, saya cenderung lebih sering mengalami ketergantungan yang tidak terpenuhi pada Windows dan Linux daripada biasanya.

Di Mac ini biasanya satu file, yang perlu Anda lakukan hanyalah mengunduh .dmg. Seringkali, ia tidak memiliki dependensi selain yang disediakan oleh MacOS itu sendiri secara default. Pengecualian adalah aplikasi kompleks yang memerlukan lingkungan eksekusi yang sesuai, misalnya Java.

Di Haiku paket unduhan .hpkg misalnya, aplikasi yang sama di java, mungkin tidak cukup, karena java mungkin ada atau tidak ada di mesin target. Apakah ada cara untuk mengunduh semua dependensi untuk paket tertentu .hpkg, selain yang diinstal secara default di Haiku dan oleh karena itu harus ada di setiap sistem Haiku?

Mac memenangkan kategori ini dengan selisih kecil.

Komentar Bpk. percikan waddle:

Untuk menulis sebuah program untuk mengumpulkan semua dependensi aplikasi sebagai satu set paket .hpkg bagi seseorang yang akrab dengan cara kerja Haiku, sekitar 15 menit sudah cukup. Menambahkan dukungan untuk hal ini tidaklah sulit jika memang benar-benar diperlukan. Tapi bagi saya ini adalah situasi yang jarang terjadi.

Mari kita tunggu sampai artikel selanjutnya di seri ini.

Memindahkan paket ke lokasi terpisah

Seperti yang saya tulis sebelumnya, saya ingin menempatkan paket saya .hpkg (baik, atau sebagian) ke tempat khusus, terpisah dari penempatan biasanya pada volume boot (partisi root). Dalam kasus yang biasa (tidak terlalu teoritis), alasannya adalah saya terus-menerus kehabisan ruang kosong pada disk (yang ada di dalamnya), tidak peduli seberapa besar disk tersebut. Dan saya biasanya menghubungkan drive eksternal atau jaringan berbagi tempat aplikasi saya berada.

Di Mac Aku hanya memindahkan paket .app ke drive yang dapat dilepas atau direktori jaringan di Finder, dan selesai. Saya masih dapat mengklik dua kali untuk membuka aplikasi seperti biasa dari volume boot. Hanya!

Di Haiku, seperti yang diberitahukan kepada saya, hal ini dapat dicapai dengan menggerakkan saya .hpkg paket ke drive yang dapat dilepas atau direktori jaringan, tetapi Anda perlu menggunakan beberapa perintah tidak berdokumen di konsol untuk memasangnya di sistem. Saya tidak tahu bagaimana melakukan ini hanya dengan menggunakan GUI.

Mac menang dalam kategori ini.

Menurut Pak. percikan waddle:

Ini adalah optimasi berdasarkan penggunaan normal. Jika ada permintaan dari lebih dari satu pengguna, kami akan menerapkannya. Bagaimanapun, ada kemungkinan penerapan pihak ketiga.

Kami akan membicarakan hal ini di artikel berikutnya.

Berbicara tentang direktori jaringan, akan sangat bagus (menurut saya pihak LAN) memiliki aplikasi jaringan yang sederhana, dapat ditemukan (seperti Zeroconf) yang dapat disalin ke komputer lokal atau dijalankan langsung dari jaringan lokal. Tentu saja, pengembang memiliki opsi untuk tidak ikut serta melalui app_flags.

Laporan akhir integrasi sistem hpkg dengan GUI

Saya pikir hal ini terutama disebabkan oleh integrasi yang relatif baru .hpkg GUI masih menyisakan banyak hal yang diinginkan. Bagaimanapun, ada beberapa hal yang dapat ditingkatkan dalam hal UX...

Satu hal lagi: Kernel Debug Land

Akan sangat bagus jika bisa memasukkan perintah saat kernel panik, misalnya syslog | grep usb. Nah, di Haiku hal itu dimungkinkan berkat Kernel Debug Land. Bagaimana Anda bisa melihat keajaiban ini beraksi jika semuanya berjalan sebagaimana mestinya tanpa membuat kernel panik? Mudah dengan menekan Alt+PrintScn+D (Debug mnemonic). Saya langsung ingat Kunci Pemrogram, yang memungkinkan pengembang Macintosh asli untuk memasukkan debugger (tentu saja jika ada yang diinstal).

Kesimpulan

Saya mulai memahami bahwa kecanggihan sistem Haiku berasal dari kenyataan bahwa pekerjaan dilakukan oleh satu tim kecil dengan fokus yang jelas pada lingkungan kerja, dengan semua lapisan sistem dapat diakses.
Sangat kontras dengan dunia Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, di mana semuanya dipecah menjadi potongan-potongan kecil sedemikian rupa sehingga abstraksi bertumpu pada abstraksi dan digerakkan dengan kruk.
Ada juga pemahaman tentang bagaimana sistemnya .hpkg menggabungkan praktik terbaik dari pengelola paket tradisional, Snappy, Flatpak, AppImage, bahkan btrfs, dan memadukannya dengan pendekatan "berfungsi" di Mac.

Seolah-olah ada sesuatu yang “beralih” di kepala saya, dan saya memahami bagaimana sistemnya .hpkg tahu cara berguling, hanya dengan melihatnya. Tapi itu bukan saya, tapi keindahan dan kesederhanaan sistemnya. Sebagian besar hal ini terinspirasi oleh semangat Mac asli.

Ya, browsing di browser mungkin tersendat-sendat dan berjalan seperti siput, aplikasi mungkin kurang (tidak ada Gtk, Electron - pengembang menyimpulkan bahwa mereka tidak cocok dengan kecanggihan), akselerasi video dan 3d mungkin sama sekali tidak ada, tapi saya tetap saja menyukai sistem ini. Bagaimanapun, hal-hal ini dapat diperbaiki dan cepat atau lambat akan muncul. Ini hanya masalah waktu dan mungkin sedikit mata merah.

Saya tidak bisa menawarkan bantuan, tapi saya pikir itu akan dimulai dari sekarang tahun Haiku di desktop.

Masalah acak

Mungkin sudah ada permintaan, atau haruskah saya membukanya?

BeScreenCapture seharusnya dapat mengekspor ke GIF seperti Peek. Ini dapat dilakukan dengan menggunakan ffmpeg, yang sudah tersedia untuk Haiku. Aplikasi.
Perangkat lunak tangkapan layar gagal menangkap jendela modal, malah menangkap seluruh layar
Anda tidak dapat memotong tangkapan layar menggunakan alat pemangkasan WonderBrush dan kemudian menyimpan hasilnya ke file
Saya tidak terlalu menyukai kursor tangan di Haiku, tapi menurut saya ini ada hubungannya dengan perasaan nostalgia yang hangat. Hal ini sangat mengganggu ketika menggunakan alat potong di Krita, karena menghasilkan pemotongan yang tidak akurat (lihat tangkapan layar dialog modal di artikel ini). Kursor crosshair akan sangat bagus. Aplikasi.

Cobalah sendiri! Bagaimanapun, proyek Haiku menyediakan gambar untuk boot dari DVD atau USB, yang dihasilkan harian. Untuk menginstal, cukup unduh gambar dan tulis ke flash drive menggunakan Penggores

Apakah Anda memiliki pertanyaan? Kami mengundang Anda ke berbahasa Rusia saluran telegram.

Ikhtisar kesalahan: Cara menembak diri sendiri di C dan C++. Kumpulan resep Haiku OS

Dari penulis terjemahan: ini adalah artikel keenam dalam seri tentang Haiku.

Daftar artikel: Pertama Kedua Третья Keempat Kelima

Sumber: www.habr.com

Hari keenam saya bersama Haiku: di balik terpal sumber daya, ikon, dan paket